Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

From: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Jeremy Schneider <schnjere(at)amazon(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Date: 2020-08-27 23:57:15
Message-ID: 8283E119-E96B-4460-87AE-67B48A2FEE03@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Aug 27, 2020, at 4:47 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Wed, Aug 26, 2020 at 12:16 PM Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)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 being discussed here is not disallowed, but if there is consensus that it is an illegal combination, we could certainly add it:

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-08-27 23:58:59 Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Previous Message Alvaro Herrera 2020-08-27 23:53:23 Re: list of extended statistics on psql