Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> systems. If we get that tor free I'd be all for it but reading
> Robert's email I'm skeptical there are easy wins here. So +1 for
> further R&D and -1 for holding things up based on full
> transparency...no harm in shooting for that, but let's look at things
> from a cost/benefit perspective (IMO).

If we could look at a patch and say "here are the cases that this
patch doesn't handle", then we could perhaps decide "we're OK with
that, let's ship the feature and document the limitations". But right
now it seems to me that we're looking at a feature where no really
systematic effort has been made to list all of the potential failure
modes, and I'm definitely not on board with the idea of shipping
something with a list of cases that are known to work and an unknown
list of failure modes. Konstantin has fixed things here and there,
but we don't know how much more there is and don't have a
well-designed plan to find all such things.

Also, I think it's worth considering that the kinds of failures users
will get out of anything that's not handled are really the worst kind.
If you have an application that relies on session state other than
what his patch knows how to preserve, your application will appear to
work in light testing because your connection won't actually be
swapped out underneath you -- and then fail unpredictably in
production when such swapping occurs. There will be no clear way to
tell which error messages or behavior differences are due to
limitations of the proposed feature, which ones are due to defects in
the application, and which ones might be due to PostgreSQL bugs.
They'll all look the same, and even experienced PG hackers won't
easily be able to tell whether a message saying "cursor XYZ doesn't
exist" (or whatever the case is specifically) is because the
application didn't create that cursor and nevertheless tried to use
it, or whether it's because the connection pooling facility silently
through it out. All of that sounds to me like it's well below the
standard I'd expect for a core feature.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company