Le vendredi 3 mai 2013 15:40:51, Heikki Linnakangas a écrit : > 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.
OK. I missed that you wanted that outside of pg_start/stop_backup() dance. > 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. Back to your first email then. +1 (as pointed by Simon, this is something we must document well: stopping at 'immediate' is sure to reduce your chance of recovering all the possible data ... opposite to recovery_target_name=ultimate, the default ;) ) -- Cédric Villemain +33 (0)6 20 30 22 52 http://2ndQuadrant.fr/ PostgreSQL: Support 24x7 - Développement, Expertise et Formation
signature.asc
Description: This is a digitally signed message part.
