Re: Recovery target 'immediate'

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Cédric Villemain <cedric(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Recovery target 'immediate'
Date: 2013-05-07 16:34:09
Message-ID: CAHGQGwHDKG76OwxJf42eOR7LutHa2iskimSx9983N6Ze0nv0JQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 7, 2013 at 9:38 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> 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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2013-05-07 16:36:57 Re: Recovery target 'immediate'
Previous Message Robert Haas 2013-05-07 16:32:09 Re: pg_dump --snapshot