From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: wal_consistency_checking reports an inconsistency on master branch |
Date: | 2018-04-13 03:08:28 |
Message-ID: | 20180413030828.GD1552@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Etsuro Fujita | 2018-04-13 03:14:45 | Re: Instability in the postgres_fdw regression test |
Previous Message | David Rowley | 2018-04-13 03:03:18 | Re: [HACKERS] path toward faster partition pruning |