pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr 7+ messages / 1 participants [nested] [flat]
* pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr @ 2025-11-04 01:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2025-11-04 01:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix unconditional WAL receiver shutdown during stream-archive transition Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of 3635a0a35aaf) introduced an unconditional WAL receiver shutdown when switching from streaming to archive WAL sources. This causes problems during a timeline switch, when a WAL receiver enters WALRCV_WAITING state but remains alive, waiting for instructions. The unconditional shutdown can break some monitoring scenarios as the WAL receiver gets repeatedly terminated and re-spawned, causing pg_stat_wal_receiver.status to show a "streaming" instead of "waiting" status, masking the fact that the WAL receiver is waiting for a new TLI and a new LSN to be able to continue streaming. This commit changes the WAL receiver behavior so as the shutdown becomes conditional, with InstallXLogFileSegmentActive being always reset to prevent the regression fixed by b4f584f9d2a1: only terminate the WAL receiver when it is actively streaming (WALRCV_STREAMING, WALRCV_STARTING, or WALRCV_RESTARTING). When in WALRCV_WAITING state, just reset InstallXLogFileSegmentActive flag to allow archive restoration without killing the process. WALRCV_STOPPED and WALRCV_STOPPING are not reachable states in this code path. For the latter, the startup process is the one in charge of setting WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to reach a WALRCV_STOPPED state after switching walRcvState, so WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is in a WALRCV_STOPPING state. A regression test is added to check that a WAL receiver is not stopped on timeline jump, that fails when the fix of this commit is reverted. Reported-by: Ryan Bird <ryanzxg@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org Backpatch-through: 13 Branch ------ REL_13_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/25b484080f14bf2a3ab3dcaa5b9304cfbc921f97 Modified Files -------------- src/backend/access/transam/xlog.c | 27 ++++++++++++++++++++++----- src/test/recovery/t/004_timeline_switch.pl | 10 +++++++++- 2 files changed, 31 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr @ 2025-11-04 01:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2025-11-04 01:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix unconditional WAL receiver shutdown during stream-archive transition Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of 3635a0a35aaf) introduced an unconditional WAL receiver shutdown when switching from streaming to archive WAL sources. This causes problems during a timeline switch, when a WAL receiver enters WALRCV_WAITING state but remains alive, waiting for instructions. The unconditional shutdown can break some monitoring scenarios as the WAL receiver gets repeatedly terminated and re-spawned, causing pg_stat_wal_receiver.status to show a "streaming" instead of "waiting" status, masking the fact that the WAL receiver is waiting for a new TLI and a new LSN to be able to continue streaming. This commit changes the WAL receiver behavior so as the shutdown becomes conditional, with InstallXLogFileSegmentActive being always reset to prevent the regression fixed by b4f584f9d2a1: only terminate the WAL receiver when it is actively streaming (WALRCV_STREAMING, WALRCV_STARTING, or WALRCV_RESTARTING). When in WALRCV_WAITING state, just reset InstallXLogFileSegmentActive flag to allow archive restoration without killing the process. WALRCV_STOPPED and WALRCV_STOPPING are not reachable states in this code path. For the latter, the startup process is the one in charge of setting WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to reach a WALRCV_STOPPED state after switching walRcvState, so WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is in a WALRCV_STOPPING state. A regression test is added to check that a WAL receiver is not stopped on timeline jump, that fails when the fix of this commit is reverted. Reported-by: Ryan Bird <ryanzxg@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org Backpatch-through: 13 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a14201073965ba8c4d6e553b044e30efbf214c20 Modified Files -------------- src/backend/access/transam/xlog.c | 14 ++++++++++---- src/backend/access/transam/xlogrecovery.c | 13 ++++++++++++- src/include/access/xlog.h | 1 + src/test/recovery/t/004_timeline_switch.pl | 8 ++++++++ 4 files changed, 31 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr @ 2025-11-04 01:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2025-11-04 01:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix unconditional WAL receiver shutdown during stream-archive transition Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of 3635a0a35aaf) introduced an unconditional WAL receiver shutdown when switching from streaming to archive WAL sources. This causes problems during a timeline switch, when a WAL receiver enters WALRCV_WAITING state but remains alive, waiting for instructions. The unconditional shutdown can break some monitoring scenarios as the WAL receiver gets repeatedly terminated and re-spawned, causing pg_stat_wal_receiver.status to show a "streaming" instead of "waiting" status, masking the fact that the WAL receiver is waiting for a new TLI and a new LSN to be able to continue streaming. This commit changes the WAL receiver behavior so as the shutdown becomes conditional, with InstallXLogFileSegmentActive being always reset to prevent the regression fixed by b4f584f9d2a1: only terminate the WAL receiver when it is actively streaming (WALRCV_STREAMING, WALRCV_STARTING, or WALRCV_RESTARTING). When in WALRCV_WAITING state, just reset InstallXLogFileSegmentActive flag to allow archive restoration without killing the process. WALRCV_STOPPED and WALRCV_STOPPING are not reachable states in this code path. For the latter, the startup process is the one in charge of setting WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to reach a WALRCV_STOPPED state after switching walRcvState, so WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is in a WALRCV_STOPPING state. A regression test is added to check that a WAL receiver is not stopped on timeline jump, that fails when the fix of this commit is reverted. Reported-by: Ryan Bird <ryanzxg@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org Backpatch-through: 13 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e7340b484c349455f77b498c9d2d2cbaa781ae09 Modified Files -------------- src/backend/access/transam/xlog.c | 14 ++++++++++---- src/backend/access/transam/xlogrecovery.c | 13 ++++++++++++- src/include/access/xlog.h | 1 + src/test/recovery/t/004_timeline_switch.pl | 8 ++++++++ 4 files changed, 31 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr @ 2025-11-04 01:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2025-11-04 01:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix unconditional WAL receiver shutdown during stream-archive transition Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of 3635a0a35aaf) introduced an unconditional WAL receiver shutdown when switching from streaming to archive WAL sources. This causes problems during a timeline switch, when a WAL receiver enters WALRCV_WAITING state but remains alive, waiting for instructions. The unconditional shutdown can break some monitoring scenarios as the WAL receiver gets repeatedly terminated and re-spawned, causing pg_stat_wal_receiver.status to show a "streaming" instead of "waiting" status, masking the fact that the WAL receiver is waiting for a new TLI and a new LSN to be able to continue streaming. This commit changes the WAL receiver behavior so as the shutdown becomes conditional, with InstallXLogFileSegmentActive being always reset to prevent the regression fixed by b4f584f9d2a1: only terminate the WAL receiver when it is actively streaming (WALRCV_STREAMING, WALRCV_STARTING, or WALRCV_RESTARTING). When in WALRCV_WAITING state, just reset InstallXLogFileSegmentActive flag to allow archive restoration without killing the process. WALRCV_STOPPED and WALRCV_STOPPING are not reachable states in this code path. For the latter, the startup process is the one in charge of setting WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to reach a WALRCV_STOPPED state after switching walRcvState, so WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is in a WALRCV_STOPPING state. A regression test is added to check that a WAL receiver is not stopped on timeline jump, that fails when the fix of this commit is reverted. Reported-by: Ryan Bird <ryanzxg@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org Backpatch-through: 13 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/da5ea6c70bc49f77547733b42461146c191a712d Modified Files -------------- src/backend/access/transam/xlog.c | 14 ++++++++++---- src/backend/access/transam/xlogrecovery.c | 13 ++++++++++++- src/include/access/xlog.h | 1 + src/test/recovery/t/004_timeline_switch.pl | 8 ++++++++ 4 files changed, 31 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr @ 2025-11-04 01:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2025-11-04 01:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix unconditional WAL receiver shutdown during stream-archive transition Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of 3635a0a35aaf) introduced an unconditional WAL receiver shutdown when switching from streaming to archive WAL sources. This causes problems during a timeline switch, when a WAL receiver enters WALRCV_WAITING state but remains alive, waiting for instructions. The unconditional shutdown can break some monitoring scenarios as the WAL receiver gets repeatedly terminated and re-spawned, causing pg_stat_wal_receiver.status to show a "streaming" instead of "waiting" status, masking the fact that the WAL receiver is waiting for a new TLI and a new LSN to be able to continue streaming. This commit changes the WAL receiver behavior so as the shutdown becomes conditional, with InstallXLogFileSegmentActive being always reset to prevent the regression fixed by b4f584f9d2a1: only terminate the WAL receiver when it is actively streaming (WALRCV_STREAMING, WALRCV_STARTING, or WALRCV_RESTARTING). When in WALRCV_WAITING state, just reset InstallXLogFileSegmentActive flag to allow archive restoration without killing the process. WALRCV_STOPPED and WALRCV_STOPPING are not reachable states in this code path. For the latter, the startup process is the one in charge of setting WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to reach a WALRCV_STOPPED state after switching walRcvState, so WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is in a WALRCV_STOPPING state. A regression test is added to check that a WAL receiver is not stopped on timeline jump, that fails when the fix of this commit is reverted. Reported-by: Ryan Bird <ryanzxg@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org Backpatch-through: 13 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/17b2d5ec759c0d26b29def7e57f51d0515ddca1f Modified Files -------------- src/backend/access/transam/xlog.c | 14 ++++++++++---- src/backend/access/transam/xlogrecovery.c | 13 ++++++++++++- src/include/access/xlog.h | 1 + src/test/recovery/t/004_timeline_switch.pl | 8 ++++++++ 4 files changed, 31 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr @ 2025-11-04 01:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2025-11-04 01:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix unconditional WAL receiver shutdown during stream-archive transition Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of 3635a0a35aaf) introduced an unconditional WAL receiver shutdown when switching from streaming to archive WAL sources. This causes problems during a timeline switch, when a WAL receiver enters WALRCV_WAITING state but remains alive, waiting for instructions. The unconditional shutdown can break some monitoring scenarios as the WAL receiver gets repeatedly terminated and re-spawned, causing pg_stat_wal_receiver.status to show a "streaming" instead of "waiting" status, masking the fact that the WAL receiver is waiting for a new TLI and a new LSN to be able to continue streaming. This commit changes the WAL receiver behavior so as the shutdown becomes conditional, with InstallXLogFileSegmentActive being always reset to prevent the regression fixed by b4f584f9d2a1: only terminate the WAL receiver when it is actively streaming (WALRCV_STREAMING, WALRCV_STARTING, or WALRCV_RESTARTING). When in WALRCV_WAITING state, just reset InstallXLogFileSegmentActive flag to allow archive restoration without killing the process. WALRCV_STOPPED and WALRCV_STOPPING are not reachable states in this code path. For the latter, the startup process is the one in charge of setting WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to reach a WALRCV_STOPPED state after switching walRcvState, so WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is in a WALRCV_STOPPING state. A regression test is added to check that a WAL receiver is not stopped on timeline jump, that fails when the fix of this commit is reverted. Reported-by: Ryan Bird <ryanzxg@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org Backpatch-through: 13 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/9b61096074af936cb3a55611b21b8b545f56cc1a Modified Files -------------- src/backend/access/transam/xlog.c | 14 ++++++++++---- src/backend/access/transam/xlogrecovery.c | 13 ++++++++++++- src/include/access/xlog.h | 1 + src/test/recovery/t/004_timeline_switch.pl | 8 ++++++++ 4 files changed, 31 insertions(+), 5 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr @ 2025-11-04 01:53 Michael Paquier <michael@paquier.xyz> 0 siblings, 0 replies; 7+ messages in thread From: Michael Paquier @ 2025-11-04 01:53 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Fix unconditional WAL receiver shutdown during stream-archive transition Commit b4f584f9d2a1 (affecting v15~, later backpatched down to 13 as of 3635a0a35aaf) introduced an unconditional WAL receiver shutdown when switching from streaming to archive WAL sources. This causes problems during a timeline switch, when a WAL receiver enters WALRCV_WAITING state but remains alive, waiting for instructions. The unconditional shutdown can break some monitoring scenarios as the WAL receiver gets repeatedly terminated and re-spawned, causing pg_stat_wal_receiver.status to show a "streaming" instead of "waiting" status, masking the fact that the WAL receiver is waiting for a new TLI and a new LSN to be able to continue streaming. This commit changes the WAL receiver behavior so as the shutdown becomes conditional, with InstallXLogFileSegmentActive being always reset to prevent the regression fixed by b4f584f9d2a1: only terminate the WAL receiver when it is actively streaming (WALRCV_STREAMING, WALRCV_STARTING, or WALRCV_RESTARTING). When in WALRCV_WAITING state, just reset InstallXLogFileSegmentActive flag to allow archive restoration without killing the process. WALRCV_STOPPED and WALRCV_STOPPING are not reachable states in this code path. For the latter, the startup process is the one in charge of setting WALRCV_STOPPING via ShutdownWalRcv(), waiting for the WAL receiver to reach a WALRCV_STOPPED state after switching walRcvState, so WaitForWALToBecomeAvailable() cannot be reached while a WAL receiver is in a WALRCV_STOPPING state. A regression test is added to check that a WAL receiver is not stopped on timeline jump, that fails when the fix of this commit is reverted. Reported-by: Ryan Bird <ryanzxg@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Reviewed-by: Noah Misch <noah@leadboat.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/19093-c4fff49a608f82a0@postgresql.org Backpatch-through: 13 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a1b8b3b2e38595efc67165cf748947a64910af0e Modified Files -------------- src/backend/access/transam/xlog.c | 27 ++++++++++++++++++++++----- src/test/recovery/t/004_timeline_switch.pl | 10 +++++++++- 2 files changed, 31 insertions(+), 6 deletions(-) ^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2025-11-04 01:53 UTC | newest] Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-04 01:53 pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr Michael Paquier <michael@paquier.xyz> 2025-11-04 01:53 pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr Michael Paquier <michael@paquier.xyz> 2025-11-04 01:53 pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr Michael Paquier <michael@paquier.xyz> 2025-11-04 01:53 pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr Michael Paquier <michael@paquier.xyz> 2025-11-04 01:53 pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr Michael Paquier <michael@paquier.xyz> 2025-11-04 01:53 pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr Michael Paquier <michael@paquier.xyz> 2025-11-04 01:53 pgsql: Fix unconditional WAL receiver shutdown during stream-archive tr Michael Paquier <michael@paquier.xyz>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox