Re: postgresql.conf error checking strategy

Bruce Momjian <bruce(at)momjian(dot)us> writes:
> Robert Haas wrote:
>> On Wed, Apr 6, 2011 at 5:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> So I'm thinking we should adopt a strategy that's less likely to result
>>> in divergent behavior among different backends. ?The idea I have in mind
>>> is to have the first "validation" pass only check that each name is a
>>> legal GUC variable name, and not look at the values at all. ?If so, try
>>> to apply all the values. ?Any that fail to apply we log as usual, but
>>> still apply the others. ?ISTM that verifying the names should be enough
>>> protection against broken files for practical purposes, and it should be
>>> something that all backends will agree on even if there are individual
>>> values that are not valid for all.
>>>
>>> Comments?

>> I don't think now is a good time for a major behavior change in this
>> area, and I'm not convinced this is the best possible design.
>>
>> There are a number of parameters which are currently PGC_POSTMASTER
>> rather than PGC_SIGHUP precisely because of the possibility of
>> backends being out of step with each other. wal_level is an obvious
>> example, and one that it would be *really* nice to be able to change
>> without a server restart. It would be nice to have a real solution to
>> that problem, but this isn't it, and I don't want to engineer it right
>> now.

> Is this a TODO?

Yes, definitely. Perhaps summarize as "rethink how we handle partially
correct postgresql.conf files". Or maybe Robert sees it as "rethink
approach to making sure all backends share the same value of critical
settings"? Or maybe those are two different TODOs?

regards, tom lane