Hi,
On 2019-01-29 20:32:54 +0900, Kyotaro HORIGUCHI wrote:
> Hello.
>
> https://www.postgresql.org/message-id/20190128.133143.115303042.horiguchi.kyotaro@lab.ntt.co.jp
>
> > C. Provide session-specific GUC variable (that overides the global one)
> > - Add new configuration file "postgresql.conf.<PID>" and
> > pg_reload_conf() let the session with the PID loads it as if
> > it is the last included file. All such files are removed at
> > startup or at the end of the coressponding session.
> >
> > - Add a new syntax like this:
> > ALTER SESSION WITH (pid=xxxx)
> > SET configuration_parameter {TO | =} {value | 'value' | DEFAULT}
> > RESET configuration_parameter
> > RESET ALL
> >
> > - Target variables are marked with GUC_REMOTE.
> >
> > I'll consider the last choice and will come up with a patch.
>
> This is that, with a small change in design.
>
> ALTER SESSION WITH (pid <pid>) SET param {TO|=} value [ IMMEDIATE ]
> ALTER SESSION WITH (pid <pid>) RESET param [ IMMEDIATE ]
> ALTER SESSION WITH (pid <pid>) RESET ALL
>
> The first form create an entry in
> $PGDATA/pg_session_conf/postgresql.<beid>.conf.
> The second form removes the entry.
> The third form removes the file itself.
>
> IMMEDIATE specifies that the change is applied immediately by
> sending SIGHUP to the process. pg_reload_conf() works as well.
>
> The session configuration is removed at session-end and the
> directory is cleaned up at startup.
>
> It can change varaibles of PGC_USERSET by non-superuser or
> PGC_SUSET by superuser. The local session user should have the
> same privileges with pg_signal_backend() on the target session.
>
> This patch contains documentation but doesn't contain test yet.
>
> I would appreciate any comments or suggestions on this.
Leaving the desirability of the feature aside, isn't this racy as hell?
I.e. it seems entirely possible that backends stop/start between
determining the PID, and the ALTER SESSION creating the file, and it
actually being processed. By the time that happens an entirely different
session might be using that pid.
And IMMEDIATE wouldn't be very immediate, considering e.g. longrunning
queries / VACUUM etc, which'll only process new config in the mainloop.
- Andres
