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

Hi Alexander,

Thanks for the script, it reproduced here as is.

On Fri, Oct 23, 2026 at 1:00 PM Alexander Lakhin
<exclusion(at)gmail(dot)com> wrote:
> That is, with v3 applied, a backend still gets stuck.

It does, and so does master: your script gives the same result on
master, 18.6 and 17.11, 3 runs out of 3 on each. DROP DATABASE waits
for the backend in SyncRepWaitForLSN(), which holds interrupts and
never absorbs the barrier. v1 terminated such a session, which shihao
pointed out; since v2 it is left alone, because its transaction has
already committed locally. The login blocks behind the two VACUUM
FULLs queued on DROP DATABASE's lock on pg_subscription.

The attached v5 is split in two. 0001 fixes your case on its own and
has no new GUC: it absorbs the barrier inside the sync-rep wait (and
in a paused COPY FROM STDIN), but only for barrier types that do
nothing commit does not already do after its commit record. The
commit message has the details, including io_method=io_uring. 0002
is the timeout part from before, on top of it.

With 0001 alone and your script, DROP DATABASE completes in 41-83 ms
and the test login in under 10 ms, while the waiter keeps waiting for
the standby; once synchronous_standby_names is reset, its COMMIT
returns without a WARNING. With a paused COPY instead, DROP completes
in under 65 ms and the COPY goes on once the client sends the rest.
Both cases are in 0001's own test, 061.

In the coverage matrix, 0001 alone clears only the sync-rep and COPY
controls, in 8-9 ms; the ClientWrite rows stay stuck as on master.
With 0002 on top they clear after the timeout as with v3, and no
control session is terminated.

Regards,
Manu