Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2019-01-29 20:52:08 -0500, Stephen Frost wrote: > > * Andres Freund (and...@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
signature.asc
Description: PGP signature
