From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15346: Replica fails to start after the crash |
Date: | 2018-08-30 17:34:35 |
Message-ID: | 20180830173435.GB15446@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs 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(at)paquier(dot)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 | Content-Type | Size |
---|---|---|
min-consistent-update-v2.patch | text/x-diff | 2.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Alexander Kukushkin | 2018-08-30 18:31:36 | Re: BUG #15346: Replica fails to start after the crash |
Previous Message | Alexander Kukushkin | 2018-08-30 14:03:43 | Re: BUG #15346: Replica fails to start after the crash |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2018-08-30 17:45:06 | Re: [HACKERS] Proposal to add work_mem option to postgres_fdw module |
Previous Message | Alvaro Herrera | 2018-08-30 17:31:59 | Re: TupleTableSlot abstraction |