On Wed, Aug 31, 2016 at 9:45 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > This is a summary of proposed changes to the recovery.conf API for > v10. These are based in part on earlier discussions, and represent a > minimal modification to current usage.
This looks great. > Proposed changes (with reference to patches from Abhijit Menon-Sen and myself) > > * pg_ctl start -M (normal|recover|continue) > pg_ctl can now start the server directly as a standby, similar to the > way pg_ctl promote works. The internal implementation is also similar, > with pg_ctl writing a "recovery.trigger" file that initiates recovery > in the same way recovery.conf used to do. It is still possible to > manually add a file called "recovery.trigger" and have that work if > users desire that mechanism. > Different startup methods can be selected with the <option>-M</option> > option. <quote>Normal</quote> mode starts the server for read/write, > overriding any previous use in Recover mode. > <quote>Recover</quote> mode starts the server as a standby server which > expects to receive changes from a primary/master server using physical > streaming replication or is used for > performing a recovery from backup. <quote>Continue</quote> mode is > the default and will startup the server in whatever mode it was in at > last proper shutdown, or as modified by any trigger files present. > (Patch: recovery_startup_r10_api.v1b.patch) I like this. I think your choice of naming is good, too. Michael suggested something else downthread, but I think it's good to call this "recover" because we don't know whether the user is doing replication or PITR or whatever; "recover" is the internal name and is fairly well-understood database jargon. > * $DATADIR/recovery.conf no longer triggers recovery > (Patch: recovery_startup_r10_api.v1b.patch) > > * Recovery parameters would now be part of the main postgresql.conf > infrastructure > Any parameters set in $DATADIR/recovery.conf will be read after the > main parameter file, similar to the way that postgresql.conf.auto is > read. > (Abhijit) Makes sense. > * pg_basebackup -R will continue to generate a parameter file called > recovery.conf as it does now, but will also create a file named > recovery.trigger. > (This part is WIP; patch doesn't include implementation for tar format yet) Hmm, OK. > * Parameters > All of the parameters formerly set in recovery.conf can be set in > postgresql.conf using RELOAD > These parameters will have no defaults in postgresql.conf.sample > Setting them has no effect during normal running, or once recovery ends. > https://www.postgresql.org/docs/devel/static/archive-recovery-settings.html > https://www.postgresql.org/docs/devel/static/recovery-target-settings.html > https://www.postgresql.org/docs/devel/static/standby-settings.html > (Abhijit) This sounds really good. > Related cleanup > * Promotion signal file is now called "promote.trigger" rather than > just "promote" > * Remove user configurable "trigger_file" mechanism - use > "promote.trigger" for all cases I'm in favor of this. I don't think that it's very hard for authors of backup tools to adapt to this new world, and I don't see that allowing configurability here does anything other than create more cases to worry about. As you can see, I don't have a lot of substance to add, but I wanted to lend my +1 to all of these proposals, which I think will improve ease of use and probably lead to easier code maintenance, too. Thanks! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
