> On 8 Jul 2026, at 12:17, Heikki Linnakangas <hlinnaka@iki.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
