On Mon, Apr 23, 2018 at 3:14 PM, Robert Haas <robertmh...@gmail.com> wrote: > In other words, transparent connection pooling is going to require > some new mechanism, which third-party code will have to know about, > for tracking every last bit of session state that might need to be > preserved or cleared. That's going to be a big project. Maybe some > of that can piggyback on existing infrastructure like > InvalidateSystemCaches(), but there's probably still a ton of ad-hoc > state to deal with. And no out-of-core pooler has a chance of > handling all that stuff correctly; an in-core pooler will be able to > do so only with a lot of work.
Why does it have to be completely transparent? As long as the feature is optional (say, a .conf setting) the tradeoffs can be managed. It's a reasonable to expect to exchange some functionality for pooling; pgbouncer provides a 'release' query (say, DISCARD ALL) to be called upon release back to the pool. Having session state objects (not all of which we are talking about; advisory locks and notifications deserve consideration) 'just work' would be wonderful but ought not to hold up other usages of the feature. merlin
