Greetings, * Tom Lane (t...@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_xid may 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
signature.asc
Description: PGP signature
