Pgbouncer pool_mode and application behavior - Mailing list pgsql-admin

From Kristjan Mustkivi
Subject Pgbouncer pool_mode and application behavior
Date
Msg-id CAOQPKauQYBMSwQV=t4mR6hsMU=whg=56h2TEEsG13aMaom2LzQ@mail.gmail.com
Whole thread Raw
Responses Re: Pgbouncer pool_mode and application behavior  (Scott Ribe <scott_ribe@elevated-dev.com>)
List 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.mustkivi@gmail.com



pgsql-admin by date:

Previous
From: Tom Lane
Date:
Subject: Re: N_live_tup value is less than actual row count in a table
Next
From: Scott Ribe
Date:
Subject: Re: Pgbouncer pool_mode and application behavior