korry wrote:
>
> On Aug 5, 2008, at 4:07 PM, Simon Riggs wrote:
>
>>
>> On Sun, 2008-08-03 at 10:36 +0200, Magnus Hagander wrote:
>>> Tom Lane wrote:
>>>> Magnus Hagander <magnus@hagander.net> writes:
>>>>>> The good way to solve this would be to have independant command line
>>>>>> utilities which check pg_hba.conf, pg_ident.conf and
>>>>>> postgresql.conf for
>>>>>> errors. Then DBAs could run a check *before* restarting the server.
>>>>
>>>>> While clearly useful, it'd still leave the fairly large foot-gun
>>>>> that is
>>>>> editing the hba file and HUPing things which can leave you with a
>>>>> completely un-connectable database because of a small typo.
>>>>
>>>> That will *always* be possible, just because software is finite and
>>>> human foolishness is not ;-).
>>>
>>> Certainly - been bitten by that more than once. But we can make it
>>> harder or easier to make the mistakes..
>>
>> Yeah. I'm sure we've all done it.
>>
>> Would it be possible to have two config files? An old and a new?
>>
>> That way we could specify new file, but if an error is found we revert
>> to the last known-good file?
>>
>> That would encourage the best practice of take-a-copy-then-edit.
>
> Perhaps the --check-config option should take an (optional) file name?
> That would allow you to validate a config file without having to copy it
> into place first.
>
> postgres --check-config=myFilenameGoesHere -D $PGDATA
If you're doing it that way, you need one for each type of file again.
And you're still not helping the vast majority who will not bother with
more than one file. They'll edit one file, and trust the system not to
load a known broken file. That's kind of like every other daemon on the
system works, so that's what people will be expecting.
//Magnus