Re: BUG #15346: Replica fails to start after the crash
От | Michael Paquier |
---|---|
Тема | Re: BUG #15346: Replica fails to start after the crash |
Дата | |
Msg-id | 20180823041420.GA1158@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #15346: Replica fails to start after the crash (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: BUG #15346: Replica fails to start after the crash
|
Список | 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
Вложения
В списке pgsql-bugs по дате отправления: