Re: ALTER SESSION

At Tue, 29 Jan 2019 21:46:28 -0500, Stephen Frost <sfrost(at)snowman(dot)net> wrote in <20190130024628(dot)GE5118(at)tamriel(dot)snowman(dot)net>
> Greetings,
>
> * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > On 2019-01-29 21:09:22 -0500, Stephen Frost wrote:
> > > * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > > > On 2019-01-29 20:52:08 -0500, Stephen Frost wrote:
> > > > > * Andres Freund (andres(at)anarazel(dot)de) wrote:
> > > > > > 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.
> > > >
> > > > I think pid would be wholly unsuitable for this, and if so we'd have to
> > > > use something entirely independent.
> > >
> > > I would think you'd use pid + other stuff (user OID, backend proc entry
> > > number, other things). Basically, if you see a file there with your pid
> > > on it, then you look and see if the other things match- if so, act on
> > > it, if not, discard the file. I still don't like this approach though,
> >
> > What do we gain by including the pid here? Seems much more reasonable to
> > use a session id that's just unique over the life of a cluster.
>
> Are you suggesting we have one of those already, or is the idea that
> we'd add a cluster-lifetime session id for this?

Just a 32 bit counter would suffice for such a period. But in the
attached the worst thing to happen is that the new session reads
the only one config line written by the last command, which don't
seem harmful.. (Of couse not the best, though.)

> > > I really don't think files are the right way to be going about this.
> >
> > Why? They persist and can be removed, they are introspectable, they
> > automatically are removed from memory when there's no demand...
>
> Well, we don't actually want these to persist, and it's because they do
> that we have to deal with removing them, and I don't see a whole lot of
> gain from them being introspectable; indeed, that seems like more of a
> drawback than anything since it will invite people to whack those files
> around and abuse them as if they were some externally documented
> interface.

.auto.conf is already a kind of such.. My first version signals
the change via shared memory (in a largely-improvable way) and
add the GUC system the complex "nontransactional SET" feature,
which lets a change persists beyond transaction end if
any. Holding changes until the session becomes idle seems also
complex.

https://www.postgresql.org/message-id/20181127.193622.252197705.horiguchi.kyotaro@lab.ntt.co.jp

The most significant reason for passing-by-file is the affinity
with the current GUC system.

> They also cost disk space, they require inodes, they have to be cleaned
> up and managed on shutdown/restart, backup tools need to understand what
> to do with them, potentially, we have to consider if we should have a
> checksum for them, we have to handle out-of-disk space cases with them,
> they could cause us to run out of disk space...

The files are so small to cause such problems easily, but I agree
that file handling is bothersome and fragile. A weak point of
signalling via shared memory is incompatibility with the current
GUC system as I mentioned above.

> These same arguments could have been made about how we could have
> implemented parallel query too. I agree that the use-case is somewhat
> different there but there's also a lot of similarity when it comes to
> managing this passing of information to that use-case.

Parallel query passes data via DSM?

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center