Re: Recovery control functions - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Recovery control functions
Date
Msg-id AANLkTi=w_t7iHKktx9Dj_BkO5AiCUD7j6BE7=fGJYtw7@mail.gmail.com
Whole thread Raw
In response to Re: Recovery control functions  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Recovery control functions  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On Sat, Jan 15, 2011 at 12:17, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Sat, 2011-01-15 at 20:11 +0900, Fujii Masao wrote:
>> On Fri, Jan 14, 2011 at 9:00 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> >> How hard would it be to have a pg_xlog_replay_until(<xlog location or
>> >> timestamp>), to have it resume recovery up to that point and then
>> >> pause again?
>> >
>> > You can already do that for timestamps.
>>
>> You mean using recovery_target_time and pause_at_recovery_target?
>> The problem is that we cannot continue recovery after the pause
>> by them. If we resume recovery after the pause, recovery ends
>> immediately.
>
> Shutdown while paused, alter parameter, restart.

That's something I'd very much like to avoid - being able to say
continue-until using the function would be very nice. Consider for
example doing this from pgadmin.

So I'm back to my original question which is, how much work would this
be? I don't know my way around that part so I can't estimate, and
what's there so far is certainly a lot better than nothing, but if
it's not a huge amount of work it would be a great improvement.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: walreceiver fallback_application_name
Next
From: Greg Smith
Date:
Subject: Re: We need to log aborted autovacuums