sql.end() never resolves when a reserved connection is released after end() was called
Maintainers usually reply within 7 days
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 82/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- javascript, node.js, postgresql
Research direction
Start by tracing sql.end(), Connection.end(), and the reserved connection's release() path; the issue identifies onopen(c) as the point that misses the ending state. Reproduce with the supplied JavaScript example, then check the shutdown behavior for a reserved connection released after end() begins. Done means end() resolves and the process can exit; the payload does not name test files.
Written by the indexing model from the issue text.
Description
When sql.end() is called while a connection is reserved, and release() is called after end() has reached that connection, the connection is put back in the pool instead of being closed. end() never resolves and the process stays alive.
import postgres from 'postgres'
const sql = postgres()
const reserved = await sql.reserve()
const ended = sql.end()
await new Promise(r => setTimeout(r, 10))
reserved.release()
await ended // never resolves
No query is needed; any query on the reserved connection that is in flight or started after end() behaves the same.
Connection.end() sees the reserved connection and waits for it to close, but release() calls onopen(c) without checking ending, so nothing terminates it.
Libraries that reserve a connection per query hit this at shutdown. For example kysely-postgres-js reserves for every query, so an in-flight better-auth request, or better-auth 1.7's startup schema check, is enough to make sql.end() hang.
Reproduced on 3.4.9 and on current master (411429e).
- Dominant language
- JavaScript
- Stars
- 8.7k
- Forks
- 389
- PR merge metrics
- No merged PRs in 30d
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from porsager/postgres
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 7 days
-
Cancelled query leaves stale row index; next query on the connection returns leading empty slotsPossibly taken @pislm claimed this 5 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 7 days
-
Reconnect after a close with a pending write never sends StartupMessage: stale nextWriteTimer/chunk make every statement fail CONNECT_TIMEOUTPossibly taken @Vengron claimed this 1 day ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 7 days
-
Connection reconnect rejects the next query with a stale ErrorResponse from before the socket closedOpen
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 7 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 7 days
All issues in porsager/postgres
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
bigskysoftware/htmx#4147 ·
Maintainers usually reply within 5 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
vshymanskyy/StandWithUkraine#316 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
bug/1-unconfirmed kind/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day