Re: PANIC during crash recovery of a recently promoted standby - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: PANIC during crash recovery of a recently promoted standby
Date
Msg-id 20180702134105.GI4841@paquier.xyz
Whole thread Raw
In response to Re: PANIC during crash recovery of a recently promoted standby  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: PANIC during crash recovery of a recently promoted standby  (Michael Paquier <michael@paquier.xyz>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Test-cases for deferred constraints in plpgsql_transaction.sql
Next
From: Jesper Pedersen
Date:
Subject: Re: [HACKERS] Fix performance degradation of contended LWLock on NUMA