On Wed, Nov 7, 2012 at 5:53 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Wed, Nov 7, 2012 at 5:19 AM, Amit Kapila <amit.kapila@huawei.com> wrote:
>>> However there is one more point which I am not able to clearly make out is
>>> how to write into file that contains
>>> all configuration parameters changed by SQL.
>
>> Perhaps you can look at pg_settings, to see if the current setting is
>> from the .auto file. If it is, then that's where it came from and it
>> should be written back there. If it's something else, that's not where
>> it came from.
>
> Note that the whole point of the one-value-per-file approach is to not
> have to figure this out.
Yeah - but I don't think that's the approach that Amit was talking
about? I thought that was a single file...
> 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.
--Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
