Re: [JDBC] Could pgsql jdbc support pool reauthentication?

just provide a PR for pgbouncer here https://github.com/pgbouncer/pgbouncer

Dave Cramer

davec@postgresintl.com

www.postgresintl.com

On 16 November 2017 at 03:30, Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:

Hello again,

After looking at pgbouncer master branch, which supports PAM authentication and indirectly LDAP, I decided to give it a go. Also I had to do some minor patches to both the backend's GUC code, and pgbouncer in order to respect search_path and make it usable with transaction_mode (which IMHO is the main benefit of using pgbouncer vs the competition) - + it is the best bet closest to re-authentication, which postgresql does not support out of the box (and is fairly complicated to do so).
After all those (not so trivial) changes I tested pgbouncer with my app, and I got sort of promising results, but also had a few unexpected failures as well.
Sad thing is that neither pgbouncer's mailing list seems very active , despite having subscribed successfully it still fails to accept my emails, nor do I see the project at github very active, or any announcement for a new release soon .

So I don't really know how to contact the pgbouncer community.

On 01/11/2017 14:55, Dave Cramer wrote:

yes, and with a bit of work you should be able to port the changes over to the current pgbouncer

Dave Cramer

davec@postgresintl.com

www.postgresintl.com

On 31 October 2017 at 07:52, Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:

On 31/10/2017 13:08, Dave Cramer wrote:

Pivotal has a branch of pgbouncer that supports LDAP.

Great news Dave, thanx, you mean this repo right ? :  https://github.com/greenplum-db/pgbouncer

Dave Cramer

davec@postgresintl.com

www.postgresintl.com

On 31 October 2017 at 07:00, Achilleas Mantzios <achill@matrix.gatewaynet.com> wrote:

On 31/10/2017 12:56, Álvaro Hernández Tortosa wrote:

On 31/10/17 10:08, Achilleas Mantzios wrote:

Hello Vladimir, thanx

On 31/10/2017 10:30, Vladimir Sitnikov wrote:

Achilleas>So if say we need 5 connections max for the most complex app to work, and we have 200 users, then at peak time, the total number of connections would have to be raised to 1000.

Pools can shrink, so you do not have to raise total number of connections to 1000 unless you truly expect 1000 concurrent connections.

I know, but we still risk having our max_connections exceeded. And this is not scaleable.

    That's true, but if you have a pgbouncer in front of PostgreSQL (you should) and the connections are used wisely (i.e. they are returned as soon as they finish the job, they don't sit idle) this is no longer a problem.

That would be a blessing if pgbouncer supported LDAP .

    Álvaro

--
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

--
Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-jdbc

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt

-- 
Achilleas Mantzios
IT DEV Lead
IT DEPT
Dynacom Tankers Mgmt