Readyset is a MySQL and Postgres wire-compatible caching layer that sits in front of existing databases to speed up queries and horizontally scale read throughput. Under the hood, ReadySet caches the results of cached select statements and incrementally updates these results over time as the underlying data changes.
Previously, the views synchronizer only checked the server for views for
queries that were in the "pending" state. This meant that if the
migration handler set a query's state to "dry run succeeded" before the
views synchronizer had a chance to check the server for a view, the query
would be stuck in the "dry run succeeded" state forever, even if a view
for the query did indeed exist already.
This commit fixes the issue by having the views synchronizer check the
server for views for queries in either the "pending" or "dry run
succeeded" states. In order to prevent the views synchronizer from
rechecking every query with status "dry run succeeded" over and over
again, a "cache" has been added to the views synchronizer to keep track
of which queries have already been checked.
While working on this, I also noticed that it was possible for the
following sequence of events to occur:
Migration handler sees that a query is pending and kicks off a dry run
migration
Views synchronizer finds a view on the server for the same query and
sets the status to "successful"
Migration handler finishes the dry run migration for the query and
overwrites the status as "dry run succeeded"
This could lead to a situation where a query that was previously
(correctly) labeled as "successful" is moved back to the "dry run
succeeded" state. To fix the issue, this commit updates the migration
handler to only write the "dry run succeeded" status if the query's
status is still "pending" after the dry run is completed.
Release-Note-Core: Fixed a bug where queries that already had caches
were sometimes stuck in the SHOW PROXIED QUERIES list
Previously, the views synchronizer only checked the server for views for queries that were in the "pending" state. This meant that if the migration handler set a query's state to "dry run succeeded" before the views synchronizer had a chance to check the server for a view, the query would be stuck in the "dry run succeeded" state forever, even if a view for the query did indeed exist already.
This commit fixes the issue by having the views synchronizer check the server for views for queries in either the "pending" or "dry run succeeded" states. In order to prevent the views synchronizer from rechecking every query with status "dry run succeeded" over and over again, a "cache" has been added to the views synchronizer to keep track of which queries have already been checked.
While working on this, I also noticed that it was possible for the following sequence of events to occur:
This could lead to a situation where a query that was previously (correctly) labeled as "successful" is moved back to the "dry run succeeded" state. To fix the issue, this commit updates the migration handler to only write the "dry run succeeded" status if the query's status is still "pending" after the dry run is completed.
Release-Note-Core: Fixed a bug where queries that already had caches were sometimes stuck in the
SHOW PROXIED QUERIESlist