Re: Recovery control functions

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Recovery control functions
Date: 2011-01-16 14:52:29
Message-ID: AANLkTi=w_t7iHKktx9Dj_BkO5AiCUD7j6BE7=fGJYtw7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Jan 15, 2011 at 12:17, Simon Riggs <simon(at)2ndquadrant(dot)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(at)2ndquadrant(dot)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/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2011-01-16 16:23:16 Re: We need to log aborted autovacuums
Previous Message Magnus Hagander 2011-01-16 14:41:14 walreceiver fallback_application_name