On Wed, Apr 25, 2018 at 2:58 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure <mmonc...@gmail.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). > > 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
Connection pooling is not a new phenomenon, and many stacks (in particular java) tend to pool connection by default. All of the problems we discuss here for the most part affect competitive solutions and I humbly submit the tradeoffs are _very_ widely understood. FWICT we get occasional reports that are simply and clearly answered. I guess there are some people dumb enough to flip GUC settings involving seemingly important things in production without testing or reading any documentation or the innumerable articles and blogs that will pop up...hopefully they are self selecting out of the industry :-). Looking at pgbouncer, they produce a chart that says, 'these features don't work, and please consider that before activating this feature' (https://wiki.postgresql.org/wiki/PgBouncer#Feature_matrix_for_pooling_modes) and that ought to be entirely sufficient to avoid that class of problems. This is very clear and simple. The main gripes with pgbouncer FWICT were relating to the postgres JDBC driver's unavoidable tendency (later fixed) to prepare 'BEGIN' causing various problems, which was a bug really (in the JDBC driver) which did in fact spill into this list. For this feature to be really attractive we'd want to simultaneously allow pooled and non-pooled connections on different ports, or even multiple pools (say, for different applications). Looking at things from your perspective, we might want to consider blocking (with error) features that are not 'pooling compatible' if they arrive through a pooled connection. merlin
