> On Aug 27, 2020, at 4:47 PM, Peter Geoghegan <pg@bowt.ie> wrote:
>
> On Wed, Aug 26, 2020 at 12:16 PM Alvaro Herrera
> <alvherre@2ndquadrant.com> wrote:
>> We could do this in stable branches, if there were any reports that
>> this inconsistency is happening in real world databases.
>
> I hope that the new heapam amcheck stuff eventually leads to our
> having total (or near total) certainty about what correct on-disk
> states are possible, regardless of the exact pg_upgrade + minor
> version paths. We should take a strict line on this stuff where
> possible. If that turns out to be wrong in some detail, then it's
> relatively easy to fix as a bug in amcheck itself.
>
> There is a high cost to allowing ambiguity about what heapam states
> are truly legal/possible. It makes future development projects harder.
The amcheck patch has Asserts in hio.c that purport to disallow writing invalid header bits to disk. The combination
beingdiscussed here is not disallowed, but if there is consensus that it is an illegal combination, we could certainly
addit:
diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c
index aa3f14c019..ca357410a2 100644
--- a/src/backend/access/heap/hio.c
+++ b/src/backend/access/heap/hio.c
@@ -47,6 +47,17 @@ RelationPutHeapTuple(Relation relation,
*/
Assert(!token || HeapTupleHeaderIsSpeculative(tuple->t_data));
+ /*
+ * Do not allow tuples with invalid combinations of hint bits to be placed
+ * on a page. These combinations are detected as corruption by the
+ * contrib/amcheck logic, so if you disable one or both of these
+ * assertions, make corresponding changes there.
+ */
+ Assert(!((tuple->t_data->t_infomask & HEAP_XMAX_LOCK_ONLY) &&
+ (tuple->t_data->t_infomask2 & HEAP_KEYS_UPDATED)));
+ Assert(!((tuple->t_data->t_infomask & HEAP_XMAX_COMMITTED) &&
+ (tuple->t_data->t_infomask & HEAP_XMAX_IS_MULTI)));
+
/* Add the tuple to the page */
pageHeader = BufferGetPage(buffer);
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
