From: | Kristjan Mustkivi <sonicmonkey(at)gmail(dot)com> |
---|---|
To: | pgsql-admin(at)lists(dot)postgresql(dot)org |
Subject: | Pgbouncer pool_mode and application behavior |
Date: | 2022-06-13 14:04:25 |
Message-ID: | CAOQPKauQYBMSwQV=t4mR6hsMU=whg=56h2TEEsG13aMaom2LzQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Hi!
Seeking advice on quite likely a really basic topic, but please excuse
my ignorance.
In our current setup, a number of java servers are connecting to the
postgres instance via a hikari pool. There are bursts of activity
where several javas require more connections than normal. Hikari
creates the number of sessions per user it is allowed to, but it is
not enough. The server engineers demand to increase the hikari pool
sizes, but all that does is cause the connections to be denied as pg
max_connections is a hard limit.
I figured to add a pgbouncer between postgres and hikari to have
pool_mode as transaction and to be able to control idle and idle in
transaction queries. Then it turned out the servers are relying on
session mode for advisory locking and prepared queries.
Am I correct to guess, that pgbouncer in this case in
pool_mode=session does not help at all and in order to improve
throughput, server engineers really must implement support for
transaction mode that pgbouncer provides?
Best regards,
--
Kristjan Mustkivi
Email: kristjan(dot)mustkivi(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Ribe | 2022-06-13 14:33:04 | Re: Pgbouncer pool_mode and application behavior |
Previous Message | Tom Lane | 2022-06-10 20:46:58 | Re: N_live_tup value is less than actual row count in a table |