-
Notifications
You must be signed in to change notification settings - Fork 454
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
adapter: correct initial timestamp determination in transactions
In #19026 various timestamp functions were refactored to allow `EXPLAIN TIMESTAMP` to reflect (and effect) the current transaction. This is tricky code and the refactor incorrectly changed the behavior of transactions. In a transaction our intention is to find a timestamp during the first statement that will be valid for any other object a user might query later in the transaction, then aquire read holds on all those referenced objects. In that change, the first statement only used the referenced IDs when determining a timestamp, not all nearby (objects in the same schema) IDs. Read holds were still correctly aquired on all nearby objects. This could cause the transaction's timestamp to not be in advance of the since of other nearby objects. For example, take two objects in the table. At the first query, object A has a since of 10, object B has a since of 20. A first query in the transaction `SELECT * FROM A` would choose 10 as its timestamp, then aquire read holds on A and B at 10. A later query in the transaction `SELECT * FROM B` would choose 10 as its timestamp (which it fetched from the in-progress transaction state), and panic because B's since is in advance of 10. One of the reasons this happened is the transaction metadata only held on to the TimestampContext. `EXPLAIN TIMESTAMP` needs a larger struct, a TimestampDetermination. Teach the session metadata to track this outer struct so EXPLAIN can use it. This allows us to now only call determine_timestamp once during transaction start, instead of during each query in a transaction. Refactor some of the other read handling code to look more like it did pre-19026.
- Loading branch information
Showing
4 changed files
with
205 additions
and
213 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.