On 2019-01-29 21:09:22 -0500, Stephen Frost wrote:
> Greetings,
>
> * Andres Freund (andres@anarazel.de) wrote:
> > On 2019-01-29 20:52:08 -0500, Stephen Frost wrote:
> > > * Andres Freund (andres@anarazel.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.
> 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...
Greetings,
Andres Freund
