Greetings,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> + <para>
> + External tools may also
> + modify <filename>postgresql.auto.conf</filename>. It is not
> + recommended to do this while the server is running, since a
> + concurrent <command>ALTER SYSTEM</command> command could overwrite
> + such changes. Such tools might simply append new settings to the end,
> + or they might choose to remove duplicate settings and/or comments
> + (as <command>ALTER SYSTEM</command> will).
> </para>
While I don't know that we necessairly have to change this langauge, I
did want to point out for folks who look at these things and consider
the challenges of this change that simply appending, when it comes to
things like backup tools and such, is just not going to work, since
you'll run into things like this:
FATAL: multiple recovery targets specified
DETAIL: At most one of recovery_target, recovery_target_lsn, recovery_target_name, recovery_target_time,
recovery_target_xidmay be set.
That's from simply doing a backup, restore with one recovery target,
then back that up and restore with a different recovery target.
Further there's the issue that if you specify a recovery target for the
first restore and then *don't* have one for the second restore, then
you'll still end up trying to restore to the first point... So,
basically, appending just isn't actually practical for what is probably
the most common use-case these days for an external tool to go modify
postgresql.auto.conf.
And so, every backup tool author that lets a user specify a target
during the restore to generate the postgresql.auto.conf with (formerly
recovery.conf) is going to have to write enough of a parser for PG
config files to be able to find and comment or remove any recovery
target options from postgresql.auto.conf.
That'd be the kind of thing that I was really hoping we could provide a
common library for.
Thanks,
Stephen