Andres Freund <and...@2ndquadrant.com> writes:
> On 2013-02-12 20:19:43 +0530, Amit Kapila wrote:
>> On Tuesday, February 12, 2013 4:55 PM Andres Freund wrote:
>>> 1) You need to grab the lock before the value is checked since some
>>> variables are interdependent (e.g. log_statement_stats, wal_level,
>>> archive_mode) and thus the check needs to be made after preventing
>>> concurrent changes.
>> This can happen if we do any SIGHUP after the command, otherwise it will
>> have old value only.
> Yes, and thats a problem imo.
That sounds to me like an entirely unreasonable requirement to put on
the patch. There is no way to positively guarantee that a value with
interdependencies will load successfully into other sessions, so why
try to enforce it at all? I note also that trying to make the value
active in the current session doesn't necessarily result in a meaningful
configuration --- what if there's an active session-level SET, for
instance? You can't just override that.
(I've said this before, but this discussion smells of overdesign every
time I look into the thread. I can't help thinking this is a big patch
with a small patch struggling to get out.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
