Re: time-delayed standbys

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: time-delayed standbys
Date: 2011-05-11 11:53:41
Message-ID: 4DCA78C5.4040803@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11.05.2011 14:16, Fujii Masao wrote:
> On Wed, May 11, 2011 at 6:50 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-05-11 11:53:47 Re: VARIANT / ANYTYPE datatype
Previous Message MauMau 2011-05-11 11:51:59 Re: Feature proposal: distinguish each PostgreSQL instance in the event log