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

On Tue, Oct 20, 2026 at 2:47 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Sun, Oct 18, 2026 at 5:14 PM shihao zhong <zhong950419(at)gmail(dot)com> 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.