Bound reconnects after clean startup closes

[diasvtumane]

If a server sends FIN during startup, the first query can hang forever while we reconnect with no delay.

Use the shared backoff for these retries and reject with CONNECTION_CLOSED if the next attempt would exceed a connect_timeout budget (30 seconds when disabled). Clear the budget after recovery or an error so later queries get a fresh start. Reserved connections also reset the retry counter after startup.

Added seven TCP regression tests for repeated closes, recovery, queued queries and reserves, and backoff beyond the timeout.

Fixes #1193.

[diasvtumane]

Hey @porsager , so sorry for the ping. This one fixes a month old issue. We hit this issue in production and it took me a minute to figure out what exactly is wrong. I will patch it in our own repo but could you take a look when you get a chance?

[jeffcoughlin]

Thanks for investigating this. I may be encountering the same failure mode in a Next.js 16.3.4 application using Drizzle, postgres.js 3.4.9, and Supabase/Supavisor.

Intermittently, all database-backed routes begin waiting for tens of seconds or several minutes, while non-database routes and the dev server can remain responsive. Restarting the Node/Next.js process immediately restores normal database behavior.

I have observed requests remaining pending for more than nine minutes even though the postgres.js client is configured with:

• connect_timeout: 5
• idle_timeout: 20
• max: 10
• prepare: false
• PostgreSQL statement_timeout: 25000

Some requests report PostgreSQL error 57014 (canceling statement due to statement timeout), while others remain pending far beyond either configured timeout. Delayed database requests sometimes complete together or only when the development process is stopped.

I have not applied this branch yet, so I cannot confirm that #1214 resolves my case. However, the clean-FIN/Supavisor startup behavior described in #1193, along with the queued-query symptoms, appears closely aligned with what I am seeing.

Please let me know if there are specific diagnostics I can capture or if testing this patch against my application would be helpful. I would also be interested to know whether this is likely to be included in an upcoming release.