Re: ALTER SESSION - Mailing list pgsql-hackers

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,

> > 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...
>
> I'm not sure which system you're referring to? Procsignals? Those rely
> on the fact that it's harmless to send such signals even when the pid
> has been recycled, so that doesn't really address the issue.  And
> realistically, you're going to need somtehing to persist such settings
> to - they're not fixed size, and using DSM here would complicate things
> to a significant degree. I don't think files would necessarily be wrong
> here, if we actually want this; alternatively we could go with some
> magic catalog, but that'd be a lot of infrastructure for not
> particularly much gain.

I would think we'd use proc signals to say "hey, go check this when you
get a chance" or similar, but, no, I was thinking for actually passing
the data we'd use a DSM.  I can see how that would complicate things but
that seems like something we might be able to solve by making it easier
to use them for this simplified use-case.

I really don't think files are the right way to be going about this.

A magic catalog sounds like an interesting idea.  Another thought I had
was something around pipes but it seems like that would require we have
pipes between every pair of backends..  Instead, I'd think we'd have a
way for any backend to plop a message into some other backend's message
queue and then that backend processes it when it gets to it.

I don't think this is going to be the last time we want to do something
like this and so having a bunch of individually built file-based systems
for passing information between backends seems really grotty.

Thanks!

Stephen