Re: BUG #15346: Replica fails to start after the crash - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: BUG #15346: Replica fails to start after the crash
Date
Msg-id 20180830173435.GB15446@paquier.xyz
Whole thread Raw
In response to Re: BUG #15346: Replica fails to start after the crash  (Alexander Kukushkin <cyberdemn@gmail.com>)
Responses Re: BUG #15346: Replica fails to start after the crash
Re: BUG #15346: Replica fails to start after the crash
List pgsql-hackers
On Thu, Aug 30, 2018 at 04:03:43PM +0200, Alexander Kukushkin wrote:
> 2018-08-30 15:39 GMT+02:00 Michael Paquier <michael@paquier.xyz>:
>> Does it take care of the problem?
>
> Yep, with the patch applied bgwriter acts as expected!

Thanks for double-checking.

I have been struggling for a couple of hours to get a deterministic test
case out of my pocket, and I did not get one as you would need to get
the bgwriter to flush a page before crash recovery finishes, we could do
that easily with a dedicated bgworker, now pg_ctl start expects the
standby to finish recovery before, which makes it harder to trigger all
the time, particularly for slow machines .  Anyway, I did more code
review and I think that I found another issue with XLogNeedsFlush(),
which could enforce updateMinRecoveryPoint to false if called before
XLogFlush during crash recovery from another process than the startup
process, so if it got called before XLogFlush() we'd still have the same
issue for a process doing both operations.  Hence, I have come up with
the attached, which actually brings back the code to what it was before
8d68ee6 for those routines, except that we have fast-exit paths for the
startup process so as it is still able to replay all WAL available and
avoid page reference issues post-promotion, deciding when to update its
own copy of minRecoveryPoint when it finishes crash recovery.  This also
saves from a couple of locks on the control file from the startup
process.

If you apply the patch and try it on your standby, are you able to get
things up and working?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: TupleTableSlot abstraction
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module