A pool survives losing an idle connection - #10
Merged
Merged
Conversation
When the server closes a connection a pool holds idle, pg emits `error` on the pool itself, and with no listener Node exits on the unhandled event. dataPool and the audit trail's pool had none, so a pg_terminate_backend, a failover or a maintenance restart took the whole service down. Both are now guarded by survivesLostConnections, which is exported for a consumer building its own pool: the lost connection is reported, the pool has already dropped it, and the next checkout opens a fresh one.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the server closes a connection that a pool holds idle (
pg_terminate_backend, a failover, a Cloud SQL maintenance restart),pgemitserroron the pool itself.dataPooland the audit trail's pool had no listener, so Node exited on the unhandled event and took the whole service down. This happened to a production service when its database was cleaned up underneath it.Both pools are now guarded by
survivesLostConnections, which is exported so a consumer that builds its own pool can use the same guard. The lost connection is reported withconsole.error; the pool has already dropped the client, and the next checkout opens a fresh one.Verified against a real Postgres: with no guard, terminating the pool's idle backend crashes the process with
Unhandled 'error' event … terminating connection due to administrator command. WithdataPool, it logs one line and the next query runs on a new backend. Unit tests cover the guard,dataPooland the barrel.