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

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

+1 to master only. I tried to break the three assumptions on current
REL_19_STABLE (c705304a0f4, which has 239c4d30699), one fresh
primary/standby pair per run, 97 runs, and they hold up:

- Since 239c4d30699 the barrier wait only happens on a wal_level=replica
standby that has a logical slot on it -- one created on the standby, or
a failover slot synced by the slotsync worker (I measured both). Without
such a slot a stuck COPY TO STDOUT or a stuck base backup no longer
delays promotion (promoted 6/6, 10-27 ms). So the restriction is a bit
narrower than it first looks.

- With the slot, the only unbounded holders were backends blocked writing
to a client that stopped reading: COPY TO STDOUT, a large SELECT, and a
base backup (still waiting past 300 s). Idle, idle in transaction,
CPU-bound queries, pg_sleep, advisory-lock and AccessExclusiveLock waits
(including a lock the startup process itself holds), slow-but-alive
readers at 256 KB/s, and cascading/logical walsenders all promoted in
under 80 ms. A client stuck in authentication releases itself at
authentication_timeout.

- Both workarounds held: wal_level=logical on the standby promoted 19/19
in ~20 ms with the same stuck clients, and pg_terminate_backend() on the
PID the startup process logs every 5 s finished the promotion in 9-73 ms
in every hung run.

One edge worth a footnote in the docs or release notes: if the stuck write
is an ErrorResponse rather than a data message, pg_terminate_backend() does
not release it, because PostgresMain sends the error with interrupts held
(HOLD_INTERRUPTS before EmitErrorReport). That is not new in 19 and the
trigger I used to reach it is contrived, but there the ways out are killing
the client connection or tcp_user_timeout on the standby (10 s -> promoted
in ~7 s); wal_level=logical avoids it too.

Happy to share the scripts and the raw per-run numbers if they're useful.

Regards,
Manu