Re: wal_consistency_checking reports an inconsistency on master branch
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Robert Haas <robertmhaas@gmail.com>
Date: 2018-04-13T03:08:28Z
Lists: pgsql-hackers
On Thu, Apr 12, 2018 at 03:36:12PM -0700, Peter Geoghegan wrote: > Without having looked at it in much detail, this seems rather more > likely to be the fault of 2f178441. That was recent enough that it's > easy to believe that I'd be the first to notice it, and actually has > on-disk changes, in the form of ItemPointerSetMovedPartitions(). Since f16241be the following comment has been added to heap_mask(): /* * NB: Not ignoring ctid changes due to the tuple having moved * (i.e. HeapTupleHeaderIndicatesMovedPartitions), because that's * important information that needs to be in-sync between primary * and standby, and thus is WAL logged. */ And actually, if you remove this query from update.sql, then the consistency checks are able to finish: UPDATE upview set c = 120 WHERE b = 4; This triggers in the test suite a CHECK violation but this should not result in a row being moved as even c is updated it would remain on the same child partition so no rows are moved across partitions here. Could this be pointing to an older issue? -- Michael
Commits
-
Improve representation of 'moved partitions' indicator on deleted tuples.
- 1667148a4dd9 11.0 landed
-
Allow UPDATE to move rows between partitions.
- 2f178441044b 11.0 cited