On Tue, Nov 5, 2019 at 9:06 AM Peter Eisentraut
<peter.eisentraut@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
