Re: Recovery target 'immediate'

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