On Tue, May 7, 2013 at 9:38 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 3 May 2013 14:40, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: >> On 03.05.2013 16:29, Bruce Momjian wrote: >>> >>> On Fri, May 3, 2013 at 01:02:08PM +0200, Cédric Villemain wrote: >>>>>>>> >>>>>>>> This changes the existing API which will confuse people that know it >>>>>>>> and invalidate everything written in software and on wikis as to how >>>>>>>> to do it. That means all the "in case of fire break glass" >>>>>>>> instructions are all wrong and need to be rewritten and retested. >>>>>>> >>>>>>> >>>>>>> Yes, *that* is the main reason *not* to make the change. It has a >>>>>>> pretty bad cost in backwards compatibility loss. There is a gain, but >>>>>>> I don't think it outweighs the cost. >>>>>> >>>>>> >>>>>> So, is there a way to add this feature without breaking the API? >>>>> >>>>> >>>>> Yes, by adding a new parameter exclusively used to control this feature, >>>>> something like recovery_target_immediate = 'on/off'. >>>> >>>> >>>> We just need to add a named restore point when ending the backup (in >>>> pg_stop_backup() ?). >>>> No API change required. Just document that some predefined target names >>>> are set >>>> during backup. >>> >>> >>> So we auto-add a restore point based on the backup label. Does that >>> work for everyone? >> >> >> Unfortunately, no. There are cases where you want to stop right after >> reaching consistency, but the point where you reach consistency is not at >> the end of a backup. For example, if you take a backup using an atomic >> filesystem snapshot, there are no pg_start/stop_backup calls, and the system >> will reach consistency after replaying all the WAL in pg_xlog. You might >> think that you can just not create a recovery.conf file in that case, or >> create a dummy recovery.conf file with restore_command='/bin/false'. >> However, then the system will not find the existing timeline history files >> in the archive, and can pick a TLI that's already in use. I found this out >> the hard way, and actually ended up writing a restore_command that restore >> timeline history files normally, but returns non-zero for any real other >> files; it wasn't pretty. >> >> Another case is that you take a backup from a standby server; you can't >> write a restore-point WAL record in a standby. >> >> If we want to avoid adding a new option for this, how about a magic restore >> point called "consistent" or "immediate": >> >> recovery_target_name='immediate' >> >> That would stop recovery right after reaching consistency, but there >> wouldn't be an actual restore point record in the WAL stream. > > recovery_target_name='something' > > ...works for me. Either constent or immediate works. > > I request that the docs recommend this be used in conjunction with > pause_at_recovery_target = on, so that the user can begin inspecting > the database at the first available point and then roll forward from > that point if desired.
And, we should forbid users from setting recovery_target_inclusive to false when recovery_target_name is set to something like 'immediate'? Because in this case, recovery would always end before reaching the consistent state and fail. Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
