From cd62759730c1c87fea6c51862a4fc40802b2bf28 Mon Sep 17 00:00:00 2001 From: Shveta Malik Date: Mon, 19 Oct 2026 23:33:08 +0530 Subject: [PATCH] fix_doc.2 --- doc/src/sgml/high-availability.sgml | 33 +++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 7253f9d8287..a74d73e1e71 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -1571,6 +1571,39 @@ postgres=# WAIT FOR LSN '0/306EE20'; read-only queries from the primary, not for high availability purposes, you don't need to promote. + + + + On a standby with set to + replica that has a valid (not invalidated) logical + replication slot at the end of recovery, including a failover slot + synchronized from the primary, promotion waits until every process has + refreshed its setting for whether to include logical decoding information + in WAL records. A backend that is blocked sending data to a client that + has stopped reading cannot do that, so promotion waits until the client + goes away or the connection is dropped, which can take a long time. + While it waits, the startup process logs a message of the form + still waiting for backend with PID + nnn to accept ProcSignalBarrier + every 5 seconds. + + + + If promotion is already waiting, calling + pg_terminate_backend on the logged process ID lets + it finish. This does not work if the backend is blocked sending an error + message, because the error is sent with interrupts held. In that case, + close the client connection. + + + + To bound such waits, configure + on the standby ahead of time, for example in + postgresql.conf, where supported by the operating + system. Setting it after a backend is already blocked sending data has + no effect on that backend. + + -- 2.34.1