From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com, robertmhaas(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, bruce(at)momjian(dot)us, GavinFlower(at)archidevsys(dot)co(dot)nz, ideriha(dot)takeshi(at)jp(dot)fujitsu(dot)com, alvherre(at)alvh(dot)no-ip(dot)org, michael(dot)paquier(at)gmail(dot)com, david(at)pgmasters(dot)net, craig(at)2ndquadrant(dot)com |
Subject: | Re: ALTER SESSION |
Date: | 2019-01-30 02:09:22 |
Message-ID: | 20190130020922.GD5118@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* 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,
> > 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-01-30 02:20:05 | Re: speeding up planning with partitions |
Previous Message | Andres Freund | 2019-01-30 01:59:07 | Re: ALTER SESSION |