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

From Michael Paquier
Subject Re: BUG #15346: Replica fails to start after the crash
Date
Msg-id 20180823041420.GA1158@paquier.xyz
Whole thread Raw
In response to Re: BUG #15346: Replica fails to start after the crash  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: BUG #15346: Replica fails to start after the crash  (Alexander Kukushkin <cyberdemn@gmail.com>)
List pgsql-bugs
On Wed, Aug 22, 2018 at 02:50:34PM -0300, Alvaro Herrera wrote:
> On 2018-Aug-22, Dmitry Dolgov wrote:
> I don't know.  I was thinking it could detect some invalid write in
> shared memory.

invalid_page_tab does not use HASH_SHARED_MEM.  What did you have in
mind?

On my side, I have been letting a primary/standby set run for a certain
amount of time with the following running:
- pgbench load on the primary.
- background worker connecting to database, just running in loop and
sleeping.  It uses BgWorkerStart_ConsistentState as start mode.
- The standby gets stopped in immediate mode, and restarted after some
time to let some activity happening after the recovery point has been
reached.

After close to an hour of repeated tests, I am not able to reproduce
that.  Maybe there are some specifics in your schema causing more
certain types of records to be created.  Could you check if in the set
of WAL segments replayed you have references to the block the hash table
is complaining about?
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #15346: Replica fails to start after the crash
Next
From: Thomas Munro
Date:
Subject: Re: BUG #15347: Unaccent for greek characters does not work