Re: ALTER SESSION - Mailing list pgsql-hackers

Greetings,

* Andres Freund (andres@anarazel.de) wrote:
> 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.

That seems like something that could possibly be fixed, by adding in
other things to make it more likely to be the 'right' backend, but my
complaint here is that we are, again, using files to pass data between
backend processes and that seems like a pretty terrible direction to be
going in.

Isn't there a whole system for passing information between different
backend processes that we could and probably should be using here
instead..?  I get that it wasn't quite intended for this originally, but
hopefully it would be possible to make it work...

> And IMMEDIATE wouldn't be very immediate, considering e.g. longrunning
> queries / VACUUM etc, which'll only process new config in the mainloop.

That's certainly a good point.

Thanks!

Stephen