Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

Andres Freund <andres@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