Re: Parsing config files in a directory

On Tue, Oct 27, 2009 at 10:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I guess all I'm saying is that if we took the approach of making SET
>> PERSISTENT rewrite postgresql.conf, we actually could let people do it
>> either way they pleased without the complexity of having multiple
>> files.
>
> You keep saying that, but what you don't seem to get is that that
> amounts to telling the people who want to go slow that they should
> go jump in a lake.  The moment they even experiment with SET PERSISTENT,
> everything they've ever done with postgresql.conf goes up in smoke.
> This is not going to be acceptable.

I guess I didn't consider the possibility that someone might reuse an
8.4 postgresql.conf on an 8.5 server. That could be awkward. But
even if they do, it's not *nearly* as bad as "everything they've ever
done with postgresql.conf goes up in smoke". I was thinking that the
algorithm would be something like: "Read the old postgresql.conf and
write it back out to a new file line by line. If, in the process of
doing this, you find a setting for the variable you're trying to
change, then write out the new line in place of the original line. If
you subsequently find anymore output lines that set that same
variable, then skip writing them to the output file altogether. If
you get to the end of the file without finding the setting you're
trying to change, then append a new line setting that variable to the
specified value."

If someone uses this on a setting that already exists - uncommented -
in their legacy postgresql.conf file, then at most they will lose any
comment on the same line as the setting they changed. The new setting
will end up on the same line in the new file as the old one, with all
the same comments around it.

If someone uses this on a setting that does not exist in their legacy
postgresql.conf file, the new setting will just be appended to the
end, while the rest of the file will remain unchanged. At worst,
they'll be surprised that the setting ended up not where they were
expecting it to be - but if they were expecting SET PERSISTENT to
notice where the commented-out version of the setting was and put the
new value there, they're going to be disappointed under any
implementation we're likely to settle on (having the new setting in a
different file altogether doesn't seem better, at least not to me).

> Furthermore, that approach is not especially simple from the tools'
> standpoint either, because then the minimum bar for doing anything at
> all is the ability to parse postgresql.conf, remove conflicting old
> settings, and add your own.  Even without any comment support, that is
> an order of magnitude harder than just dropping a prebuilt file into a
> directory, which is feasible for at least some use-cases with the
> directory approach.

True, but actually having a good SET PERSISTENT command would solve
most of this problem, because the tools could just use that. The
ability to just drop in a file is superficially attractive, but I
think it's a red herring. Whatever settings the tool sets will still
potentially be set elsewhere in other files (maybe even files created
by other tools). So tool A comes and drops in a file that sets
work_mem, checkpoint_segments, and wal_buffers, and then tool B comes
along and sets max_connections, a couple of autovacuum settings, and
checkpoint_segments again. Then tool C comes along and does something
else again, and now the DBA wants to change a setting with SET
PERSISTENT, while the other DBA edits postgresql.conf using $EDITOR.

We may have tools to tell you which file is providing the value for
any particular parameter, but I don't think they're going to make this
kind of situation un-confusing. Normally, you're going to want the
value for any particular parameter to be the one the value to which it
was most recently changed, and that just won't be the case with this
setup, at least not without some pretty substantial gymnastics.

...Robert