> On 8 Jul 2026, at 12:17, Heikki Linnakangas <[email protected]> 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
v2026-07-08-0001-injection_points-drive-wait-points-throu.patch
Description: Binary data
v2026-07-08-0002-injection_points-test-that-pre-auth-back.patch
Description: Binary data
