Re: Init connection time grows quadratically

On Fri, Sep 18, 2026 at 3:55 AM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> > Maybe I am just missing something, but is this ever a benefit outside of
> > completely arbitrary scenarios?
>
> On Andres's question, the closest workload I have seen is an AI app
> behind pgbouncer. Some transactions stay open while they wait for an LLM
> response, and background loading causes transactionid and tuple lock
> waits. In spikes, pgbouncer grew to about 4000 server connections, then
> shrank again.
>
> The real problem there is locks and long transactions. This patch might help
> the connection storm, but may not fix it.
>

I'm afraid PostgreSQL is not ready to deterministically handle those kind of
connection counts, but that doesnt mean people don't run such setups anyway.

I'm afraid nothing will help the connection storm until the issue is diagnosed
(root cause of what is causing it) and then stuff is (re)configured properly.
But... kind it's unrelated to this $patch itself that I saw stuff like that
happening from time to time in the field/production systems, but we are often
completley blind to connection rates and/or saturating postmaster in the first
place, so rarely people solve those issues until it's way too late. I've tried
to propose some damage control to that in [1] so at least users would know
this - at least partially for postmaster saturation cases, v3 just logs:
> postmaster potentially overloaded, stats: avg 2905.00 conns/sec; 2904.00 disconns/sec; 0.00 parallel workers started/sec; CPU: user: 0.01 s, system: 0.97 s, elapsed: 1.00

Kind of related is that I've also tried to have PoC for throtthing rates
of incoming connections, but had some issues there (basically be able to
throttle to like e.g. 30 TCP new conns per sec per single IP or /24 network;
that exactly assumes you are DBA and trying to damage-control some rouge
user), but the issue there in how we throw error to the client (which AFAIR
libpq interprets as some kind of generic error and there is no way to explictly
say to the client *you've been throttled, slow down* something like HTTP/429,
because the way interpret every error as some security issue there, I can dig
more details on this if someone is interested).

-J.

[1] - https://www.postgresql.org/message-id/flat/CAKZiRmxeTNAe_VZ9m%3Drt%3D5155mvL%3DCFsQ4ENJWhuUdgMe%3D_Udg%40mail.gmail.com