-2

I'm exploring the use of PgBouncer as a connection pooler for my PostgreSQL database. While it's been promising so far, I've encountered a challenge: if the database goes down or restarts during an operation, PgBouncer doesn't seem to handle it gracefully.

I have tried tweaking server_login_retry by setting

server_login_retry=3600

but that did not help

Is PgBouncer designed to manage such scenarios? If not, are there alternative tools or setups that can provide more resilience against database interruptions?

Dakait
  • 2,531
  • 1
  • 25
  • 43
  • 1
    A connection pool is *not* a retry mechanism. If a database goes down all connections go down as well. You can't just reconnect and retry stuff, as any pending transactions were also rolled back. You can't retry step 42 in a transaction if all previous changes were lost – Panagiotis Kanavos Aug 22 '23 at 17:34
  • Can you pl suggest any retry mechanisms? Thanks for the explanation, that helps. – Dakait Aug 22 '23 at 17:45
  • Retry for *what*? There's no simple answer to that. If you really don't want disruptions, use a failover cluster. Otherwise you'll have to retry the entire *business* operation. No automatic mechanism can guess what was changed and committed, what can be retried and what can't. – Panagiotis Kanavos Aug 22 '23 at 17:52
  • Retry database operation. For example client applications are reading and writing to database and during that if database restarts is there a possibility that we pause of delay "already running" operations until database comes back online. Maybe that is not possible I am not that experienced that is why i seek guidance :) Thanks again for your time and explanations. – Dakait Aug 23 '23 at 12:09

0 Answers0