On Wed, Nov 7, 2012 at 12:29 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> On Wed, Nov 7, 2012 at 6:19 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.
> That doesn't fix it either, at least not without a whole lot of other
> changes --- we don't normally read the config file within-commands,
> and there are both semantic and implementation problems to overcome
> if you want to do so.
Why would you need to? It seems to me that we ought to be able to
rewrite a machine-generated configuration file without loading those
values into the current session. If we can't, that seems like prima
facie evidence that the format is not sufficiently easy to
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2012-11-07 18:58:13|
|Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL|
|Previous:||From: Tom Lane||Date: 2012-11-07 17:52:22|
|Subject: Re: Extend libpq to support mixed text and binary results|