Re: [PG19] Promotion hangs behind a backend blocked on a stuck client

On Sun, Oct 18, 2026 at 5:14 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Masahiko,
>
> I would still like 0001 in 19, because the cases that remain are the
> HA ones.
>
> After 239c4d30699 the wait only happens when the standby has a logical
> slot, and Manu measured that a failover slot synced by the slotsync
> worker is enough. That is exactly the setup of an HA cluster that
> keeps logical replication across failover.
>
> A network split or a dead app host leaves such a client behind.
> Promotion then waits until TCP gives up, which may took up to 15 minutes
>
> The workarounds need someone to know about this ahead of time, and
> most failover tools do not terminate backends before promoting.
>
> If you still prefer master only, I am fine with it and we need to
> add that into the doc note for 19.

TBH I'm still unsure that the 0001 patch is the correct approach.
ProcessProcSignalBarrier() is written on the assumption that a handler
can raise an error. That's why it has a PG_TRY block for a later
retry. In v19 we have only two handlers, ProcessBarrierSmgrRelease()
and ProcessBarrierUpdateXLogLogicalInfo(), and neither raises an
error. But on master, AbsorbDataChecksumsBarrier() raises an error on
purpose, with a comment saying it "will be caught by the procsignal
machinery for a later retry". With 0001 that error would terminate the
session instead of being retried. So the assumption that 0001 adds is
already false on master.

Other possible solutions are: (1) send the signal barrier at promotion
only when we really need to send it. In other words, if we know that
logical decoding has been enabled from the startup and no change
happened during the recovery, we can skip it even if wal_level =
replica. (2) the startup process terminates the backend who doesn't
absorb the barrier, like as we resolve the recovery conflicts.

(1) would narrow further the case where we need the wait, but doesn't
eliminate the case completely. (2) sounds more promising to me, and we
already have similar machinery such as
ResolveRecoveryConflictWithVirtualXIDs(). Probably it could help DROP
DATABASE too: TerminateOtherDBBackends() terminates only the backends
connected to the target database, so FORCE doesn't help today if a
backend connected to another database doesn't absorb the SMGRRELEASE
barrier.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com