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

From Heikki Linnakangas
Subject Re: time-delayed standbys
Date
Msg-id 4DCA78C5.4040803@enterprisedb.com
Whole thread Raw
In response to Re: time-delayed standbys  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers
On 11.05.2011 14:16, Fujii Masao wrote:
> On Wed, May 11, 2011 at 6:50 PM, Heikki Linnakangas
> <heikki.linnakangas@enterprisedb.com>  wrote:
>> 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.
>
> Okay. But I'd like to add the following assertion check just before
> ShutdownWalRcv() which you added, in order to detect such a bug
> that we found this time, i.e., the bug which causes unexpected end
> of recovery. Thought?
>
>      Assert(reachedStopPoint || !WalRcvInProgress())

There's no unexpected end of recovery here. The recovery ends when we 
reach the target, as it should. It was the assumption that WAL receiver 
can't be running at that point anymore that was wrong.

That assertion would work, AFAICS, but I don't think it's something we 
need to assert. There isn't any harm done if WAL receiver is still 
running, as long as we shut it down at that point.

>> Committed a patch to do that.
>
> Thanks. Should we backport it to 9.0? 9.0 has the same problem.

Ah, thanks, missed that, Cherry-picked to 9.0 now as well.

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


pgsql-hackers by date:

Previous
From: "MauMau"
Date:
Subject: Re: Feature proposal: distinguish each PostgreSQL instance in the event log
Next
From: Robert Haas
Date:
Subject: Re: VARIANT / ANYTYPE datatype