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

Hi Fujii,

> I think it's better to backpatch this to v19, since commit 67c20979ce7
> introduced the unnecessary barrier wait. Thoughts?

+1, and thanks for the comment fixes. Only the comments changed from
0003, and they read right to me. I ran v3 on REL_19_STABLE: it applies
cleanly there and on master, and make check and the recovery suite pass.
Unpatched 19 hung 12/12 on promotion with one backend stuck writing to a
client; with v3 it promoted 12/12 in 10-27 ms. Unpatched 18 promoted
12/12 in the same time, so 19 is the only branch that needs it.

v3 only covers promotion without logical slots. Shihao's 0001, which
came with his report, is the general fix for when the wait is real.
Since 0001 and his test will need backpatching too, I ran them on 15
through master. Shihao, the full numbers are in the attachment; in
short:

- 060 is now taken on every branch (060_multixact_crashed_updater.pl
went in today), so the test needs another number. 061 is free
everywhere. Renumbered and otherwise unchanged, it passes with 0001
on 17 through master, recovery suite included.
- On 15 and 16 it dies before testing anything: psql there runs
FETCH_COUNT through a cursor, so the backend never blocks. psql()
there also returns 0 on timeout, so the DROP DATABASE check can pass
while DROP DATABASE is still stuck.
- Once v3 is in, promotion with no slot doesn't wait at all, so the
promotion subtest passes without 0001.

The attached diff is a suggestion for all three: a COPY TO STDOUT writer,
a timed_out check, and a logical slot on the standby (19 and master
only). With it the test fails without 0001 and passes with it on 15
through master. The COPY writer also helps on its own: on unpatched
master the promotion subtest caught the hang 5/5 with it, against 1/5
as it stands. It's your test, so take whatever is useful.

Hayato, I could reproduce what you found: with your change, DROP DATABASE
stays blocked behind a backend in COPY FROM STDIN, 6/6, with or without
v3. So it's in 0001's absorb path, and v3 neither causes nor fixes it.
It's latent today: every barrier callback, in 19 and master, returns
true or throws ERROR, and none of about 1800 calls over the recovery
suite returned false. If 0001 wants to guard against it, setting the
latch again when ProcSignalBarrierPending is still set (second attached
diff) cleared your reproducer 3/3. A plain Assert there could fire
spuriously, since a new barrier can arrive right after the call.

Regards,
Manu