# LogicTest: default parallel-stmts distsql

# This test verifies that when a SNAPSHOT transaction reads without
# uncertainty, it actually does that. We had a performance bug which caused the
# MaxTimestamp to be set to the Timestamp instead of OrigTimestamp on such
# reads, which always left the interval (OrigTimestamp, Timestamp) open to
# read uncertainty errors.

statement ok
CREATE TABLE t (a INT)

statement ok
GRANT ALL on t TO testuser

# UserA starts the first transaction.
statement ok
BEGIN TRANSACTION ISOLATION LEVEL SNAPSHOT

# The SELECT forces the timestamp to be chosen.
query I
SELECT * FROM t
----

# UserB starts a transaction and inserts into the table.
# TransactionB operates at a timestamp higher than TransactionA since we're
# single-node and TransactionA has already picked its timestamp.
user testuser

# Insert a write that will show up in the future of TransactionA when it
# tries to read.
statement ok
INSERT INTO t VALUES (1)

# Touch all keys with a timestamp ahead of TransactionA. This means
# the next write by TransactionA will push it into the future, and
# in particular, into the future of the INSERT just above.
query I
SELECT * FROM t
----
1

user root

# This insert forces TransactionA's timestamp ahead, so that we have
# OrigTimestamp < InsertTS < Timestamp < ObservedTimestamp
statement ok
INSERT INTO t VALUES (2)

# We (always) read at OrigTimestamp, and since this is a single node system
# the read will always be certain. With the bug, we would still be uncertain
# on (OrigTimestamp, Timestamp) and since we're running with a sizable
# clock offset in these tests, the below would catch an uncertainty error.
query I
SELECT * FROM t
----
2

# Cleanup.
statement ok
COMMIT
