Horton
Menu

Re: Fix bug in multixact Oldest*MXactId initialization and access

Chao Li <li.evan.chao@gmail.com>

View thread
From: Chao Li <li.evan.chao@gmail.com>
To: Sami Imseih <samimseih@gmail.com>, Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-02T04:08:02Z
Lists: pgsql-hackers 

> On Mar 2, 2026, at 10:34, Sami Imseih <samimseih@gmail.com> wrote:
> 
>> New version attached.
> 
> The comment here:
> 
> +static inline MultiXactId *
> +PreparedXactOldestMemberMXactIdSlot(ProcNumber procno)
> +{
> +       /*
> +        * The entries with indexes >= MaxBackends in the OldestMemberMXactId
> +        * array are reserved for regular backends.
> 
> should say "array are reserved for prepared transactions"
> 

+1

And I saw the other code comment in multixact.c around line 162 needs an update because of this patch:
```
* Per-backend data starts here. We have two arrays stored in the area
* immediately following the MultiXactStateData struct. Each is indexed by
* ProcNumber.
```

It says “Each is indexed by ProcNumber”, but it’s no longer accurate for OldestMemberMXactId prepared-xact entries, which now use index (procno - FIRST_PREPARED_XACT_PROC_NUMBER).

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add test for row-locking and multixids with prepared transactions

  2. Skip prepared_xacts test if max_prepared_transactions < 2

  3. Fix OldestMemberMXactId and OldestVisibleMXactId array usage

  4. Redefine backend ID to be an index into the proc array

  5. Fix an old bug in multixact and two-phase commit. Prepared transactions can