On Sun, Oct 18, 2026 at 5:14 PM shihao zhong <[email protected]> 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
