On Wed, Apr 25, 2018 at 10:09 PM, Michael Paquier <mich...@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
