On Wed, Nov 7, 2012 at 6:19 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.net> writes: >> On Wed, Nov 7, 2012 at 5:53 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> I'm not sure that the above approach works anyway --- for instance, the >>> "current setting" might be a SET LOCAL result, in which case you still >>> don't know anything about what the appropriate thing to put into the >>> file is. I think there are probably also race conditions with cases >>> where somebody else just changed some other setting but your session >>> hasn't absorbed it yet. > >> Well, you don't have to look at pg_settings specifically - since this >> is inside the backend. You can look at the underlying structures. We >> stack them up so we can RESET them, right? So we could just peek up in >> that stack and find the data there. > > You could dig it out of the stack if it's there, but that doesn't fix > the race-condition aspect. Now a race is inevitable if two sessions try > to set the *same* variable, but I think people will be unhappy if a SET > on one variable makes a recent SET on some other variable disappear.
I think if we require an exclusive lock on a single global lock for "set permanent", people are quite ok with that, really. Changing permanent settings concurrently doesn't seem like a veyr likely scenario. > The one-value-per-file solution neatly bypasses all these problems, > which is why this topic got put on the back burner originally until > we had the include-directory functionality. I don't see why we are > revisiting the bugs in an approach that was already rejected. Yeah, agreed - that certainly takes most of it away. And there is nothing preventing somebody from having both that and another directory-include somewhere if they'd like to... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
