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-26T20:44:32Z
Lists: pgsql-hackers 
> (Sorry, I've used Google Translate to write this sentence).
>
> When you write assert, you protect yourself from shooting your leg far in
> the future. Believe me.

The issue to me seems that we a few code paths that rely on the
total proc calculation in several places, and changing one and
forgetting to change another is what broke things. I am all for
future proofing this, and I think simply centralizing the calculation
should be enough without adding complexity to the code.

Maybe others have a different opinion.

--
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