Re: proposal: a validator for configuration files

From: Florian Pflug <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alexey Klyukin <alexk(at)commandprompt(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Selena Deckelmann <selena(at)chesnok(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: proposal: a validator for configuration files
Date: 2011-06-20 16:49:31
Message-ID: 91F6251F-8015-4CBD-99BF-3A1E0DF09B2B@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jun20, 2011, at 18:16 , Tom Lane wrote:
> Florian Pflug <fgp(at)phlo(dot)org> writes:
>> The code the actually implements the "check settings first, apply later" logic
>> isn't easy to read. Now, assume that this code has a bug. Then, with your
>> patch applied, we might end up with the postmaster applying a setting (because
>> it didn't abort early) but the backend ignoring it (because they did abort early).
>> This is obviously bad. Depending on the setting, the consequences may range
>> from slightly confusing behaviour to outright crashes I guess...
>
> This is already known to happen: there are cases where the postmaster
> and a backend can come to different conclusions about whether a setting
> is valid (eg, because it depends on database encoding). Whether that's
> a bug or not isn't completely clear, but if this patch is critically
> dependent on the situation never happening, I don't think we can accept
> it.

Does that mean that some backends might currently choose to ignore an
updated config file wholesale on SIGUP (because some settings are invalid)
while others happily apply it? Meaning that they'll afterwards disagree
even on modified settings which *would* be valid for both backends?

Or do these kinds of setting rejections happen late enough to fall out
of the all-or-nothing logic in ProcessConfigFile?

Anyway, the patch *doesn't* depend on all backends's setting being in sync.
The issue we were discussion was whether it's OK to add another small risk
of them getting out of sync by aborting early on errors in backends but
not in the postmaster. I was arguing against that, while Alexey was in favour
of it, on the grounds that it reduces log traffic (but only at DEBUG2 or
beyond).

best regards,
Florian Pflug

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-06-20 16:57:29 Re: ALTER TABLE lock strength reduction patch is unsafe
Previous Message Florian Pflug 2011-06-20 16:37:28 Re: Adding a distinct "pattern" type to resolve the "~" commutator stalemate