Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN() - Mailing list pgsql-hackers

From Asim Praveen
Subject Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()
Date
Msg-id CANXE4TfddjO1oBbQsX-CsBfG=n6+kE1hPEksyuviH8B6va5nTQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] [PATCH] Assert that the correct locks are held whencalling PageGetLSN()  (Michael Paquier <michael.paquier@gmail.com>)
List 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
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] taking stdbool.h into use
Next
From: Simon Riggs
Date:
Subject: Re: [HACKERS] Transaction control in procedures