On Tue, Nov 5, 2019 at 9:06 AM Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > Yeah, the problem I see here is this: Client 1 uses language driver A, > client 2 uses language driver B. Connection pooling is in use, and they > both connect to the same pool. Everyone is happy. > > Now this feature gets introduced. Language driver A is updated to > transparently ask for GUC "foo" to be reported, because it uses it > internally. Now how it connection pooling supposed to work in this > situation?
Good point. > There either needs to be a way to change reported parameters during a > session that this can be run when an existing backend connection is > assigned to a pooler client. Or the connection pooler would need to be > changed to create separate pools for each different setting of the > to-be-reported list, just like it already creates separate pools for > different users and databases, since you can't change those after > session start either. Both of these options are not without problems. > We should have a complete plan for this before implementing the feature > in the server. +1. Based on this, it seems to me that we actually do need a way to change the list of reportable GUCs. However, it also seems to me that it needs to be done via a protocol level mechanism (which is also how RESET SESSION AUTHORIZATION ought to work). Drivers can avoid letting protocol messages be sent if the effect of those messages will create a configuration they can't support. They can't prevent SQL from being executed, unless they can solve the halting problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
