Re: time-delayed standbys - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: time-delayed standbys
Date
Msg-id 4DCA5BEC.2020805@enterprisedb.com
Whole thread Raw
In response to Re: time-delayed standbys  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: time-delayed standbys  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 11.05.2011 08:29, Fujii Masao wrote:
> On Sat, May 7, 2011 at 10:48 PM, Robert Haas<robertmhaas@gmail.com>  wrote:
>> I was able to reproduce something very like this in unpatched master,
>> just by letting recovery pause at a named restore point, and then
>> resuming it.
>
> I was able to reproduce the same problem even in 9.0. When the standby
> reaches the recovery target, it always tries to end the recovery even
> though walreceiver is still running, which causes the problem. This seems
> to be an oversight in streaming replication. I should have considered how
> the standby should work when recovery_target is specified.
>
> What about the attached patch? Which stops walreceiver instead of
> emitting PANIC there only if we've reached the recovery target.

I think we can just always call ShutdownWalRcv(). It should be gone if 
the server was promoted while streaming, but that's just an 
implementation detail of what the promotion code does. There's no hard 
reason why it shouldn't be running at that point anymore, as long as we 
kill it before going any further.

Committed a patch to do that.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Andreas Joseph Krogh
Date:
Subject: Re: potential bug in trigger with boolean params
Next
From: Cédric Villemain
Date:
Subject: Re: the big picture for index-only scans