Re: Recovery target 'immediate'

On 3 May 2013 14:40, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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. That would cover my concern that this stopping
point is arbitrary and not intrinsically worth stopping at of itself.

Can I suggest that we discuss a range of related changes together? So
we have a roadmap of agreed changes in this area. That will be more
efficient than discussing each one individually; often each one makes
sense only as part of the wider context.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services