On Tue, Oct 20, 2026 at 2:47 AM Masahiko Sawada <[email protected]> wrote: > > On Sun, Oct 18, 2026 at 5:14 PM shihao zhong <[email protected]> wrote: > > 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. >
Right, for example, If the first logical slot appeared on the primary shortly before promotion, replay toggled the status (false→true), the case counts as "changed," and the wait remains. So, the same problem still exists. > (2) sounds more promising to me, and we > already have similar machinery such as > ResolveRecoveryConflictWithVirtualXIDs(). > Like ResolveRecoveryConflictWithVirtualXIDs(), we may want to wait for sometime (which needs GUC or a fixed time wait) before terminating the backend. I think this is a direction worth pursuing but I feel it is too late for v19 considering the amount/complexity of changes required. I feel for v19, we can add a Note in the docs with a workaround and then discuss the more robust solution for HEAD. -- With Regards, Amit Kapila.
