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

On Thu, Oct 15, 2026 at 8:27 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi,
>
> Hayato, you are right, thanks. v4-0001 sets the latch again if a
> barrier is still pending, as Manu suggested. With your change on top,
> DROP DATABASE waited 60 seconds with v2-0001 and 15 ms with v4-0001.
>
> Manu, I took all of your test changes. On 19 and master the test fails
> without 0001 and passes with it.

I agree that 0001 is what fixes the rest. I'm reviewing it now, but
what I'm unsure about is whether to include it in v19 at this point.
It creates a new place where barrier callbacks run in the middle of a
protocol message, with any ERROR upgraded to FATAL, and every barrier
type we add later will have to be safe there. Neither of the two types
in v19 throws today, so this is more about what could break there
later, but it's the kind of change I'd want more time on than RC gives
us.

From the numbers upthread, a backend blocked writing to the client
(for example COPY TO STDOUT, or taking a base backup) looks like the
only case that is both likely and unbounded; the others either release
themselves or can't happen on a standby. It also needs a consumer that
has stopped rather than one that is just slow.

There are workarounds in the meantime. Setting wal_level=logical on
the standby skips the barrier entirely thanks to the recent commit. If
it does happen, the startup process logs the holding PID every five
seconds, and pg_terminate_backend() on that PID lets the promotion
finish.

So I'm currently leaning towards master only and we live with the
restriction in v19. Feedback is very welcome.

Regards,

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