Horton
Menu

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

Sami Imseih <samimseih@gmail.com>

View thread
From: Sami Imseih <samimseih@gmail.com>
To: Yura Sokolov <y.sokolov@postgrespro.ru>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>, Andres Freund <andres@anarazel.de>, Chao Li <li.evan.chao@gmail.com>
Date: 2026-02-25T21:53:09Z
Lists: pgsql-hackers 
Hi.

> All accesses are validated with asserts certainly.

Maybe I am missing something, but the extra asserts and wrapper
functions being proposed seem unnecessary for this purpose.
We know the total number of procs, so we just need to make this
available to all code paths that need to index by pgprocno.

If that calculation ever changes, code like multixact.c will not
need to care.

This can be done, as mentioned earlier, by defining the total
number of procs in proc.h, which can then be used by both
multixact.c and InitProcGlobal.

```
#define TOTAL_PROCS (MaxBackends + NUM_AUXILIARY_PROCS + max_prepared_xacts)
```

and to calculate where the prepared transaction procs start:

```
PreparedXactProcs = &procs[TOTAL_PROCS - max_prepared_xacts];
```

What do you think?

With regards to v3, I got a compilation warning that `GetOldestVisibleMXactId`
is an unused function.

--
Sami Imseih
Amazon Web Services (AWS)

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