On 26.04.2018 05:09, Michael Paquier 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.
> --
> Michael
Sorry, may be I do not understand you correctly. But GUCs are already
handled by builtin connection pooler.
It is done at guc.c level, so doesn't matter how GUC variable is
changed. All modified GUCs are saved into the session context and
restored on reschedule.
But there are some other static variables which are not related with
GUCs. Most of them are really associated with backend, not with session.
So them should not be handled by reschedule.
But there may be some variables which are intended to be session
specific. And locating this variables is really non trivial task.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
