Re: Built-in connection pooling - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Built-in connection pooling
Date
Msg-id 20180426020908.GD18940@paquier.xyz
Whole thread Raw
In response to Re: Built-in connection pooling  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Built-in connection pooling
Re: Built-in connection pooling
List pgsql-hackers
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.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: pg_recvlogical broken in back branches
Next
From: Craig Ringer
Date:
Subject: Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS