Re: ALTER SESSION
От | Andres Freund |
---|---|
Тема | Re: ALTER SESSION |
Дата | |
Msg-id | 20190130015907.455vgatajsreti4r@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: ALTER SESSION (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: ALTER SESSION
|
Список | pgsql-hackers |
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. > 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: