Re: Built-in connection pooling - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Built-in connection pooling
Date
Msg-id 24725.1524164484@sss.pgh.pa.us
Whole thread Raw
In response to Re: Built-in connection pooling  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Built-in connection pooling  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> Greetings,
> * Andres Freund (andres@anarazel.de) wrote:
>> On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote:
>>> However, I suspect that dealing with *all* of the issues is going to be hard
>>> and tedious. And if there are any significant gaps, things that don't work
>>> correctly with the pooler, the patch will almost certainly be rejected.

>> FWIW, I think that's not the right course. We should work towards an
>> in-core pooler. There's very few postgres installations that don't need
>> one, and there's a lot of things that are very hard to do without closer
>> integration.

> I tend to agree with this and things like trying to proxy authentication
> are really not ideal, since it involves necessairly trusting another
> system.

FWIW, I concur with Heikki's position that we're going to have very high
standards for the transparency of any in-core pooler.  Before trying to
propose a patch, it'd be a good idea to try to fix the perceived
shortcomings of some existing external pooler.  Only after you can say
"there's nothing wrong with this that isn't directly connected to its
not being in-core" does it make sense to try to push the logic into core.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: ON CONFLICT DO UPDATE for partitioned tables
Next
From: Heikki Linnakangas
Date:
Subject: Re: initdb fails to initialize data directory