Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()

Поиск
Список
Период
Сортировка
От Asim Praveen
Тема Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
Дата
Msg-id CANXE4TfddjO1oBbQsX-CsBfG=n6+kE1hPEksyuviH8B6va5nTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
Список pgsql-hackers
Hi Michael

On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier <michael.paquier@gmail.com> wrote:

Did you really test WAL replay? This still ignores that PageGetLSN is
as well taken in some code paths, like recovery, where actions on the
page are guaranteed to be serialized, like during recovery, so this
patch would cause the system to blow up. Note that pageinspect,
amcheck and wal_consistency_checking also process on page copies. So
the assertion failure of 0002 would trigger in those cases.

Indeed, the assertion tripped during WAL replay on the standby.  This was caught by TAP tests under src/test/recovery.  The assertion is now fixed so that WAL replay is exempt from the check.  Please find the new patch attached.  The tests now pass with the fix.  I also manually verified that recovery works with "wal_consistency_checking=all".

Asim
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] taking stdbool.h into use
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [HACKERS] Transaction control in procedures