You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current blocking query docs primarily state how to use blocking queries, and could be expanded to include additional details about their behavior. Here are a couple ideas on behavior that could be documented about them:
Index returned for various queries
Depending on the query, the index returned can vary. At times it is the max index for the table, at times it is the max index of the result set, at times it is the index of a given resource.
Behavior of blocking on resources that don't exist
When a blocking query is set up for a resource that doesn't exist, such as a KV key, unrelated key updates can lead to the blocking query firing. This is due to how memdb will watch for changes, and the fact that when the resource doesn't exist the index considered by the query is the max for the table/partition/namespace.
This issue is being addressed in #12110, but the existing behavior should be documented since it has been a cause for confusion/concern in several deployments.
The text was updated successfully, but these errors were encountered:
The current blocking query docs primarily state how to use blocking queries, and could be expanded to include additional details about their behavior. Here are a couple ideas on behavior that could be documented about them:
Index returned for various queries
Depending on the query, the index returned can vary. At times it is the max index for the table, at times it is the max index of the result set, at times it is the index of a given resource.
Behavior of blocking on resources that don't exist
When a blocking query is set up for a resource that doesn't exist, such as a KV key, unrelated key updates can lead to the blocking query firing. This is due to how memdb will watch for changes, and the fact that when the resource doesn't exist the index considered by the query is the max for the table/partition/namespace.
This issue is being addressed in #12110, but the existing behavior should be documented since it has been a cause for confusion/concern in several deployments.
The text was updated successfully, but these errors were encountered: