Re: postgresql.conf error checking strategy

On Sun, May 8, 2011 at 1:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?

The second is what I had in mind. I'm thinking that at least for
critical GUCs we need a different mechanism for making sure everything
stays in sync, like having the postmaster write a precompiled file and
convincing the backends to read it in some carefully synchronized
fashion. However, it's not clear to me whether something along those
lines (or some other lines) would solve the problem you were
complaining about; therefore it's possible, as you say, that there are
two separate action items here. Or maybe not: maybe someone can come
up with an approach that swats both problems in one go.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company