On 7 December 2016 at 10:19, Tom Lane <t...@sss.pgh.pa.us> wrote: > What it sounds like to me is building a connection pooler into the > backend. I'm not really convinced we ought to go there.
If we do, it probably needs to be able to offer things that out-of-tree ones can't. The main things I see that you can't do sensibly with an out-of-tree pooler are: * Re-use a backend for different session users. You can SET SESSION AUTHORIZATION, but once you hand the connection off to the client they can just do it again or RESET SESSION AUTHORIZATION and whammo, they're a superuser. Same issue applies for SET ROLE and RESET ROLE. * Cope with session-level state when transaction pooling. We probably can't do anything much about WITH HOLD cursors, advisory locks, etc, but we could save and restore GUC state and a few other things, and we could detect whether or not we can save and restore state so we could switch transparently between session and transaction pooling. * Know, conclusively, whether a query is safe to reroute to a read-only standby, without hard coded lists of allowed functions, iffy SQL parsers, etc. Or conversely, transparently re-route queries from standbys to a read/write master. In other words, we could start to separate session state from executor state in a limited manner. That'd definitely be valuable, IMO; it's a real shame that Pg's architecture so closely couples the two. So - is just doing "PgInCoreBouncer" a good idea? No, I don't think so. But there are potentially good things to be done in the area. What I don't see here is a patch, or a vague proposal for a patch, so I'm not sure how this can go past the hot-air stage. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
