HEAP_XMAX_COMMITTED with mutlixid

From: Andy Fan <zhihuifan1213(at)163(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: HEAP_XMAX_COMMITTED with mutlixid
Date: 2026-02-12 01:44:59
Message-ID: 87qzqqlopw.fsf@163.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hi,

I find our implementation:

(1) discards the HEAP_XMAX_COMMITTED on purposes when it converts a
HEAP_XMAX_COMMITTED xmax into a mutlixid. See the branch of "else if
(old_infomask & HEAP_XMAX_COMMITTED)" in compute_new_xmax_infomask
(new_infomask is computed in GetMultiXactIdHintBits where the
HEAP_XMAX_COMMITTED is totally ignored).

(2) Again in compute_new_xmax_infomask, we have:

else if (old_infomask & HEAP_XMAX_IS_MULTI)
{
MultiXactStatus new_status;

/*
* Currently we don't allow XMAX_COMMITTED to be set for multis, so
* cross-check.
*/
Assert(!(old_infomask & HEAP_XMAX_COMMITTED));

My question is why we couldn't let HEAP_XMAX_COMMITTED with mutlixid?
IIUC there are only one "deleter xmax" in mutlixid's members, so could
we define the HEAP_XMAX_COMMITTED as the status of the "deleter xmax" in
the multixacts? With this way, it can reduce some calls of
TransactionIdDidCommit in HeapTupleSatisfiesMVCC case.

--
Best Regards
Andy Fan

Browse pgsql-hackers by date

  From Date Subject
Next Message Shinya Kato 2026-02-12 02:05:42 Re: remove unnecessary include in src/backend/commands/policy.c
Previous Message Shinya Kato 2026-02-12 01:41:23 Re: Avoid recalculating pgprocno in ProcArrayAdd()