4 ms·

Unfortunately, no. Spanner may garbage collect the snapshot timestamp to which your example query was bound, if the garbage collection policy was triggered by

Unfortunately, no. Spanner may garbage collect the snapshot timestamp to which your example query was bound, if the garbage collection policy was triggered by additional writes at greater timestamps, or by the simple passage of time. The result of the second query may be a permanent error indicating that your data has disappeared. Spanner had a transactional MVCC system in their original implementation described in the 2012 paper which predates SQL support described in the 2017 paper. Therefore it is probably wrong to credit SQL with Spanner's MVCC system.

derefr 8y ago
> The result of the second query may be a permanent error indicating that your data has disappeared. That's actually okay, per SQL. Any SQL transaction may fail, for any reason, at the server's discretion. Because the user's permission to operate on the table was revoked in the middle of their transaction, for example. Or because the server is going down and wants to drop connections. SQL clients have to be written to assume that any transaction could enter a failed state "before" the execution of a statement, even if the previous statement returned a success. Helpfully, though, they know that 1. by the SQL standard, that failure means that no part of the transaction applied; and 2. that this failure-state is a failure of the transaction context to be valid, rather than a failure of their statement to be valid. (They don't know that their statement is valid, but they know that they haven't been told that it isn't.)