Greetings,
* Andres Freund (andres@anarazel.de) wrote:
> On 2018-04-18 06:36:38 -0400, Heikki Linnakangas wrote:
> > On 18/04/18 06:10, Konstantin Knizhnik wrote:
> > > But there are still use cases which can not be covered y external
> > > connection pooler.
> >
> > Can you name some? I understand that the existing external connection
> > poolers all have their limitations. But are there some fundamental issues
> > that can *only* be addressed by a built-in implementation?
> >
> > For the record, I think an internal connection pool might be a good idea. It
> > would presumably be simpler to set up than an external one, for example. But
> > it depends a lot on the implementation. If we had an internal connection
> > pool, I would expect it to be very transparent to the user, be simple to set
> > up, and not have annoying limitations with prepared statements, temporary
> > tables, etc. that the existing external ones have.
> >
> > 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.
> >
> > I'd recommend that you put your effort in improving the existing external
> > connection poolers. Which one is closest to suit your needs? What's missing?
> >
> > There are probably things we could do in the server, to help external
> > connection poolers. For example, some kind of a proxy authentication, where
> > the connection pooler could ask the backend to do authentication on its
> > behalf, so that you wouldn't need to re-implement the server-side
> > authentication code in the external pooler. Things like that.
>
> 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. Perhaps it'd be nice to be able to proxy auth cleanly, and in
some cases it may be required to have another system involved (I've
certainly seen cases of multi-layered pgbouncer), but I'd rather only do
that when we need to instead of almost immediately...
Thanks!
Stephen