Re: Built-in connection pooling

On Wed, Apr 25, 2018 at 10:09 PM, Michael Paquier <michael@paquier.xyz> wrote:
> On Wed, Apr 25, 2018 at 03:42:31PM -0400, Robert Haas wrote:
>> The difficulty of finding them all is really the problem.  If we had a
>> reliable way to list everything that needs to be moved into session
>> state, then we could try to come up with a design to do that.
>> Otherwise, we're just swatting issues one by one and I bet we're
>> missing quite a few.
>
> Hm?  We already know about the reset value of a parameter in
> pg_settings, which points out to the value which would be used if reset
> in a session, even after ebeing reloaded.  If you compare it with the
> actual setting value, wouldn't that be enough to know which parameters
> have been changed at session-level by an application once connecting?
> So you can pull out a list using such comparisons.  The context a
> parameter is associated to can also help.

Uh, there's a lot of session backend state other than GUCs.  If the
only thing that we needed to worry about were GUCs, this problem would
have been solved years ago.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company