agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: Say what WAIT's snapshot restriction actually is 2+ messages / 1 participants [nested] [flat]
* pgsql: Say what WAIT's snapshot restriction actually is @ 2026-09-18 06:39 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Alexander Korotkov @ 2026-09-18 06:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Say what WAIT's snapshot restriction actually is The reference page said WAIT "cannot be used in contexts where such a snapshot must remain active, including transactions running at isolation levels higher than READ COMMITTED", which reads as a blanket ban at those levels. It is not one. The rule the code enforces is that the current transaction must hold no snapshot, and a transaction-snapshot-mode transaction has no snapshot until its first query: WaitStmt is exempt in PlannedStmtRequiresSnapshot(), so the command itself does not take one. WAIT therefore works before that first query, which is the order an application wants anyway, and it is what 447aae13b03 set out to allow by keeping the wait snapshot-free. State the rule in terms of the snapshot rather than the isolation level, say that WAIT acquires none of its own and name the other ways to hold one, and give the consequence of holding one: it can delay replay, which standby_replay waits for and which the other standby modes ultimately depend on as well. The error for a held snapshot named the internal snapshot states instead of saying what the user did, and attached the isolation-level explanation as DETAIL unconditionally, so a READ COMMITTED session with a cursor was told its isolation level was too high. Report what is held rather than how it is held, and emit the DETAIL only when the isolation level is in fact the reason. Reported-by: Sami Imseih <samimseih.pg@gmail.com> Reported-by: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Sami Imseih <samimseih.pg@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/CAN12%2BYJddgAZzA36JZFX%2BYrnNR7Uubp9qWFz6ASs3v0kL30AMA%40mail.gmail.com Backpatch-through: 19 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/26a3c0a45cc6017ee7f334c0ef63292d5e101b58 Modified Files -------------- doc/src/sgml/ref/wait.sgml | 14 ++++++++++---- src/backend/commands/wait.c | 6 ++++-- src/test/recovery/t/049_wait_for_lsn.pl | 27 ++++++++++++++++++++++++++- 3 files changed, 40 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Say what WAIT's snapshot restriction actually is @ 2026-09-18 06:39 Alexander Korotkov <akorotkov@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Alexander Korotkov @ 2026-09-18 06:39 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Say what WAIT's snapshot restriction actually is The reference page said WAIT "cannot be used in contexts where such a snapshot must remain active, including transactions running at isolation levels higher than READ COMMITTED", which reads as a blanket ban at those levels. It is not one. The rule the code enforces is that the current transaction must hold no snapshot, and a transaction-snapshot-mode transaction has no snapshot until its first query: WaitStmt is exempt in PlannedStmtRequiresSnapshot(), so the command itself does not take one. WAIT therefore works before that first query, which is the order an application wants anyway, and it is what 447aae13b03 set out to allow by keeping the wait snapshot-free. State the rule in terms of the snapshot rather than the isolation level, say that WAIT acquires none of its own and name the other ways to hold one, and give the consequence of holding one: it can delay replay, which standby_replay waits for and which the other standby modes ultimately depend on as well. The error for a held snapshot named the internal snapshot states instead of saying what the user did, and attached the isolation-level explanation as DETAIL unconditionally, so a READ COMMITTED session with a cursor was told its isolation level was too high. Report what is held rather than how it is held, and emit the DETAIL only when the isolation level is in fact the reason. Reported-by: Sami Imseih <samimseih.pg@gmail.com> Reported-by: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Sami Imseih <samimseih.pg@gmail.com> Reviewed-by: Xuneng Zhou <xunengzhou@gmail.com> Discussion: https://postgr.es/m/CAN12%2BYJddgAZzA36JZFX%2BYrnNR7Uubp9qWFz6ASs3v0kL30AMA%40mail.gmail.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/6fe990f348ae891df69f77bf3e63ff2489dac6fc Modified Files -------------- doc/src/sgml/ref/wait.sgml | 14 ++++++++++---- src/backend/commands/wait.c | 6 ++++-- src/test/recovery/t/049_wait_for_lsn.pl | 27 ++++++++++++++++++++++++++- 3 files changed, 40 insertions(+), 7 deletions(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-09-18 06:39 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-09-18 06:39 pgsql: Say what WAIT's snapshot restriction actually is Alexander Korotkov <akorotkov@postgresql.org> 2026-09-18 06:39 pgsql: Say what WAIT's snapshot restriction actually is Alexander Korotkov <akorotkov@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox