Re: PANIC during crash recovery of a recently promoted standby

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: pavan(dot)deolasee(at)gmail(dot)com, alvherre(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PANIC during crash recovery of a recently promoted standby
Date: 2018-07-02 13:41:05
Message-ID: 20180702134105.GI4841@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 02, 2018 at 04:25:13PM +0900, Kyotaro HORIGUCHI wrote:
> When minRecoveryPoint is invalid, there're only two possible
> cases. It may be at very beginning of archive reovery or may be
> running a crash recovery. In the latter case, we have detected
> crash recovery before redo starts. So we can turn off
> updateMinRecoveryPoint immediately and no further check is
> needed and it is (I think) easier to understand.

Er, you are missing the point that updateMinRecoveryPoint is also used
by processes, like the checkpointer, other than the startup process,
which actually needs to update minRecoveryPoint and rely on the default
value of updateMinRecoveryPoint which is true...

I am planning to finish wrapping this patch luckily on Wednesday JST
time, or in the worst case on Thursday. I got this problem on my mind
for a couple of days now and I could not find a case where the approach
taken could cause a problem. Opinions are welcome.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2018-07-02 13:54:40 Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA
Previous Message Tom Lane 2018-07-02 13:37:43 Re: Test-cases for deferred constraints in plpgsql_transaction.sql