Hi Michael On Mon, Nov 6, 2017 at 6:18 PM, Michael Paquier <michael.paqu...@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
0002-PageGetLSN-assert-that-locks-are-properly-held.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
