Use replay LSN as target for cascading logical WAL senders
authorMichael Paquier <michael@paquier.xyz>
Mon, 2 Jun 2025 03:03:59 +0000 (12:03 +0900)
committerMichael Paquier <michael@paquier.xyz>
Mon, 2 Jun 2025 03:03:59 +0000 (12:03 +0900)
A cascading WAL sender doing logical decoding (as known as doing its
work on a standby) has been using as flush LSN the value returned by
GetStandbyFlushRecPtr() (last position safely flushed to disk).  This is
incorrect as such processes are only able to decode changes up to the
LSN that has been replayed by the startup process.

This commit changes cascading logical WAL senders to use the replay LSN,
as returned by GetXLogReplayRecPtr().  This distinction is important
particularly during shutdown, when WAL senders need to send any
remaining available data to their clients, switching WAL senders to a
caught-up state.  Using the latest flush LSN rather than the replay LSN
could cause the WAL senders to be stuck in an infinite loop preventing
them to shut down, as the startup process does not run when WAL senders
attempt to catch up, so they could keep waiting for work that would
never happen.

Backpatch down to v16, where logical decoding on standbys has been
introduced.

Author: Alexey Makhmutov <a.makhmutov@postgrespro.ru>
Reviewed-by: Ajin Cherian <itsajin@gmail.com>
Reviewed-by: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/52138028-7246-421c-9161-4fa108b88070@postgrespro.ru
Backpatch-through: 16

src/backend/replication/walsender.c

index 9fa8beb6103d3c9c63b1277c35e0783d8b46a367..f2c33250e8b2f7761af1f4324376ef7695174a2b 100644 (file)
@@ -3449,8 +3449,16 @@ XLogSendLogical(void)
    if (flushPtr == InvalidXLogRecPtr ||
        logical_decoding_ctx->reader->EndRecPtr >= flushPtr)
    {
+       /*
+        * For cascading logical WAL senders, we use the replay LSN instead of
+        * the flush LSN, since logical decoding on a standby only processes
+        * WAL that has been replayed.  This distinction becomes particularly
+        * important during shutdown, as new WAL is no longer replayed and the
+        * last replayed LSN marks the furthest point up to which decoding can
+        * proceed.
+        */
        if (am_cascading_walsender)
-           flushPtr = GetStandbyFlushRecPtr(NULL);
+           flushPtr = GetXLogReplayRecPtr(NULL);
        else
            flushPtr = GetFlushRecPtr(NULL);
    }