On Fri, Sep 18, 2026 at 3:55 AM shihao zhong <[email protected]> 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
