On 2019-10-12 05:05, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2019-10-11 16:30:17 -0400, Robert Haas wrote:
>>> But, if it does need to be changed, it seems like a terrible idea to
>>> allow it to be done via SQL. Otherwise, the user can break the driver
>>> by using SQL to set the list to something that the driver's not
>>> expecting, and there's nothing the driver can do to prevent it.
>
>> Uhm. The driver can just ignore GUCs it's not interested in, like our
>> docs have told them for a long time?
>
> Certainly it should do that; but the problematic case is where it
> *doesn't* get told about something it's depending on knowing about.
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?
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
