Re: Implement waiting for wal lsn replay: reloaded
Alexander Korotkov <aekorotkov@gmail.com>
On Mon, Apr 6, 2026 at 10:15 AM Xuneng Zhou <xunengzhou@gmail.com> wrote: > > On Mon, Apr 6, 2026 at 2:01 PM Xuneng Zhou <xunengzhou@gmail.com> wrote: > > > > On Mon, Apr 6, 2026 at 11:26 AM Xuneng Zhou <xunengzhou@gmail.com> wrote: > > > > > > Hi Alexander, > > > > > > On Sun, Apr 5, 2026 at 8:31 PM Alexander Korotkov <aekorotkov@gmail.com> wrote: > > > > > > > > On Thu, Jan 29, 2026 at 9:47 AM Alexander Korotkov <aekorotkov@gmail.com> wrote: > > > > > On Tue, Jan 27, 2026 at 3:14 AM Xuneng Zhou <xunengzhou@gmail.com> wrote: > > > > > > Heikki spotted a misplaced wake-up call for replay waiters in > > > > > > PerformWalRecovery. He suggested that the WaitLSNWakeup needs to be > > > > > > invoked immediately after wal record is applied to avoid the potential > > > > > > missed wake-ups when recovery stops/pauses/promotes. It makes sense to > > > > > > me. Please check the attached patch to fix that. > > > > > > > > > > Pushed, thank you! > > > > > > > > I've assembled small patches, which I think worth pushing before v19 FF. > > > > > > > > 1. Avoid syscache lookup in WaitStmtResultDesc(). This is [1] patch, > > > > but I've removed redundant comment in ExecWaitStmt(), which explained > > > > the same as WaitStmtResultDesc() comment. > > > > 2. Use WAIT FOR LSN in wait_for_catchup(). I made the following > > > > changes: fallback to polling on not_in_recovery result instead of > > > > croaking, avoid separate pg_is_in_recovery() query, comment why we > > > > may face the recovery conflict and why it is safe to detect this by > > > > the error string. > > > > 3. A paragraph to the docs about possible recovery conflicts and their reason. > > > > > > > > I'm going to push this on Monday if no objections. > > > > > > > > Links. > > > > 1. https://www.postgresql.org/message-id/CABPTF7U%2BSUnJX_woQYGe%3D%3DR9Oz%2B-V6X0VO2stBLPGfJmH_LEhw%40mail.gmail.com > > > > 2. https://www.postgresql.org/message-id/CABPTF7X0n%3DR50z2fBpj3EbYYz04Ab0-DHJa%2BJfoAEny62QmUdg%40mail.gmail.com > > > > > > I'll review them shortly. > > > > > > > Here're some comments: > > > > 1) Patch 2 checks for not_in_recovery, but WAIT FOR ... NO_THROW > > returns “not in recovery”, which appears to prevent the > > promoted-standby fallback described in the patch from triggering. > > Instead, it seems to result in a hard failure. > > > > There are some behavior changes that I overlooked earlier: > > > > 2) Patch 2 changes the helper from "wait until timeout if there is no > > active replication connection" to "connect to the standby immediately > > and fail on ordinary connection failures". This appears to differ from > > the current contract and may affect cases where the standby is down, > > restarting, or not yet accepting SQL. > > > > "If there is no active replication connection from this peer, waits > > until poll_query_until timeout." > > > > 3) In patch 2, we returns success as soon as the standby locally > > reaches the target LSN, but the existing helper is explicitly defined > > in terms of pg_stat_replication ... state = 'streaming' on the > > upstream. So the new path can report success even when there is no > > active replication connection from that peer anymore. > > > > "The replication connection must be in a streaming state." > > > > I’m not sure whether these semantic changes are intended. > > > > After some thoughts, these semantic changes appear to be improvements > over the artifacts of polling-based behavior. The pg_stat_replication > ... state = 'streaming' is a precondition of polling works rather than > a post-condition check. The retry timeout also has nothing to do with > the edge cases and the state of the standby. > > In practice, wait_for_catchup() is called when the standby is expected > to be up. If it's not, one of two things is true: > > The standby is briefly restarting -> start() already waits for > readiness before returning, so this is a non-issue. > The standby is genuinely down -> waiting 180 seconds to time out > wastes CI time compared to failing fast. > > I’ve addressed point 1 and updated the comments accordingly to reflect > the new behavior. Please check it. Thank you, I've pushed your version of patchset. I made two minor corrections for patch #2: mention default mode value in the header comment, and fallback to polling on has_wal_read_bug sparc64+ext4 bug. ------ Regards, Alexander Korotkov Supabase
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Clean up 019_replslot_limit.pl comments
- 0b866bb90368 19 (unreleased) landed
-
Stabilize 019_replslot_limit.pl: wait on slot restart_lsn
- cdb1d1cf1de6 19 (unreleased) landed
-
Fix memory ordering in WAIT FOR LSN wakeup mechanism
- a80a593ab636 19 (unreleased) landed
-
Improve WAIT FOR LSN test coverage
- cb096e6d6981 19 (unreleased) landed
-
Remove redundant WAIT FOR LSN caller-side pre-checks
- df9f938ca2ec 19 (unreleased) landed
-
Use barrier semantics when reading/writing writtenUpto
- dfb690dd5237 19 (unreleased) landed
-
Use replay position as floor for WAIT FOR LSN standby_(write|flush)
- cba67b5b87f9 19 (unreleased) landed
-
Wake standby_write/standby_flush waiters from the WAL replay loop
- e7cd592174d9 19 (unreleased) landed
-
Minimal fix for WAIT FOR ... MODE 'standby_flush'
- 29e7dbf5e4da 19 (unreleased) landed
-
Avoid syscache lookup while building a WAIT FOR tuple descriptor
- 834038c1f8d5 19 (unreleased) landed
-
Document that WAIT FOR may be interrupted by recovery conflicts
- 10484c2cc75b 19 (unreleased) landed
-
Use WAIT FOR LSN in PostgreSQL::Test::Cluster::wait_for_catchup()
- 7e8aeb9e483d 19 (unreleased) landed
- f30848cb05d4 19 (unreleased) landed
-
Wake LSN waiters before recovery target stop
- 20a8f783e15c 19 (unreleased) landed
-
Remove redundant pg_unreachable() after elog(ERROR) from ExecWaitStmt()
- 30776ca46865 19 (unreleased) landed
-
Revert "Use WAIT FOR LSN in PostgreSQL::Test::Cluster::wait_for_catchup()"
- e54ce0b2da62 19 (unreleased) landed
-
Fix variable usage in wakeupWaiters()
- bf308639bfcf 19 (unreleased) landed
-
Add tab completion for the WAIT FOR LSN MODE option
- 76948337f724 19 (unreleased) landed
-
Add the MODE option to the WAIT FOR LSN command
- 49a181b5d634 19 (unreleased) landed
-
Extend xlogwait infrastructure with write and flush wait types
- 7a39f43d885b 19 (unreleased) landed
-
Unify error messages
- 502e256f2262 19 (unreleased) cited
-
Optimize shared memory usage for WaitLSNProcInfo
- 75e82b2f5a6f 19 (unreleased) landed
-
Fix WaitLSNWakeup() fast-path check for InvalidXLogRecPtr
- ede6acef4967 19 (unreleased) landed
-
Fix incorrect function name in comments
- 23792d738158 19 (unreleased) landed
-
Add infrastructure for efficient LSN waiting
- 3b4e53a075ea 19 (unreleased) landed
-
Add pairingheap_initialize() for shared memory usage
- 8af3ae0d4b36 19 (unreleased) landed
-
Implement WAIT FOR command
- 447aae13b030 19 (unreleased) landed