porsager / porsager/postgres

Handle PostgresError: remaining connection slots are reserved for non-replication superuser connections at ErrorResponse

Open
#1,036 0 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
8.7k
Forks
374
Avg merge
11d 16h
Merged PRs (30d)
1

Description

It seems to me we might be better if we queue up queries or begin calls and hand out connections to run those and if we have no more connections allow the queue to grow as big as it needs with some setting like connectionTimeoutMillis to time them out. If the query hits that amount of time waiting for a open connection then throwing timeout error on the pool.

I am new to this project but would love to contribute and add this but would the team be open to a change this big or not? At this point I am going to switch back to pg-promise because I really need this functionality. We want to run way more requests then available sql connects when we get spiky traffic. If I stayed using this library I would have to add my own pool in front of this library and manual connect and release to do this with this library. Or maybe I am missing something? I love how much faster and nicer this library is but that one thing is breaking this project I am working on now.

So what I am saying is if we get this error we don't fail but wait for another connect to be open to run the query. Maybe just log a warning. If another query is tried to start and we haven't hit our connection limit we will try to connect again but same thing in we queue up the query if no connects are available or it fails to connect for any reason.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files, tests, or entry points. Start by tracing how Postgres.js opens, queues, and releases connections, then define timeout behavior for work waiting on an available connection. Done would require an agreed design and coverage for connection saturation and timeout cases.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, postgresql
Domain
backend, databases
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.