Re: injection_points: Switch wait/wakeup to use atomics rather than latches

> On 8 Jul 2026, at 12:17, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>
> dead-end backends, max_connections, reserved_connections and all that

Hi Heikki, Michael,

Thanks for pushing the atomics patch. Following Heikki's pointer to
waits before authentication and the connection-limit area, here is where
I looked:

- 002_connection_limits.pl did not seem to need a blocking wait, closer to the
WARNING/LOG point (as discussed on the postmaster-cleanup thread [0]).

- 007_pre_auth.pl already attaches init-pre-auth, but it exists to test
pg_stat_activity itself, and its old race (matching state='starting'
before the backend reached the point) is already fixed by querying
wait_event. So converting it buys little, as you noted.

- So PFA a new test: a connection counts against max_connections
from InitProcessPhase2(), before authentication. I added a TAP test
that fills every slot with pre-auth backends and checks that one more
connection is refused with "too many clients". Such backends can't be
identified over SQL and there is no free slot for a monitoring session,
so the test finds them through the filesystem markers. If this test
direction seems viable - I'll polish the test.

Is this enough to justify the filesystem layer, or would you rather see
more cases? Heikki, if you have a specific dead-end-backend /
reserved-connection scenario in mind, I'm happy to aim the test there.

It would be slightly better to have an unfixed bug to close with such
test. But I do not have a spare one, so of course we could introduce a
new bug. But that clearly deserves its own thread.

Thanks!

Best regards, Andrey Borodin.

[0] https://postgr.es/m/ggflhkciwdyotpoie323chu2c2idpjk5qimrn462encwx2io7s@thmcxl7i6dpw