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
signature.asc
Description: PGP signature
