Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adapter: correct initial timestamp determination in transactions #20267

Merged
merged 1 commit into from
Jul 5, 2023

Commits on Jul 5, 2023

  1. adapter: correct initial timestamp determination in transactions

    In MaterializeInc#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.
    maddyblue committed Jul 5, 2023
    Configuration menu
    Copy the full SHA
    0b176dd View commit details
    Browse the repository at this point in the history