public inbox for [email protected]  

help / color / mirror / Atom feed

Repeatable Read Isolation Level "transaction start time"
2+ messages / 2 participants
[nested] [flat]

* Repeatable Read Isolation Level "transaction start time"
@ 2024-09-23 15:15  Wizard Brony <[email protected]>
  0 siblings, 1 reply; 2+ messages in thread

From: Wizard Brony @ 2024-09-23 15:15 UTC (permalink / raw)
  To: [email protected]

https://www.postgresql.org/docs/16/transaction-iso.html#XACT-REPEATABLE-READ

The PostgreSQL documentation for the Repeatable Read Isolation Level states the following:

“UPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE commands behave the same as SELECT in terms of searching for target rows: they will only find target rows that were committed as of the transaction start time.”

What is defined as the "transaction start time?" When I first read the statement, I interpreted it as the start of the transaction:

BEGIN;
SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

But in my testing, I find that according to that statement, the transaction start time is actually "the start of the first non-transaction-control statement in the transaction" (as mentioned earlier in the section). Is my conclusion correct, or am I misunderstanding the documentation?





^ permalink  raw  reply  [nested|flat] 2+ messages in thread

* Re: Repeatable Read Isolation Level "transaction start time"
@ 2024-09-24 14:28  Tom Lane <[email protected]>
  parent: Wizard Brony <[email protected]>
  0 siblings, 0 replies; 2+ messages in thread

From: Tom Lane @ 2024-09-24 14:28 UTC (permalink / raw)
  To: Wizard Brony <[email protected]>; +Cc: [email protected]

Wizard Brony <[email protected]> writes:
> But in my testing, I find that according to that statement, the transaction start time is actually "the start of the first non-transaction-control statement in the transaction" (as mentioned earlier in the section). Is my conclusion correct, or am I misunderstanding the documentation?

It's even looser than that, really: it's the first statement that
requires an MVCC snapshot.  From memory, LOCK TABLE is an important
exception --- you can acquire table locks before pinning down
a snapshot, and this is important in some scenarios.

			regards, tom lane






^ permalink  raw  reply  [nested|flat] 2+ messages in thread

end of thread, other threads:[~2024-09-24 14:28 UTC | newest]

Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-09-23 15:15 Repeatable Read Isolation Level "transaction start time" Wizard Brony <[email protected]>
2024-09-24 14:28 ` Tom Lane <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox