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.
- Heikki
