Horton
Menu

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

Yura Sokolov <y.sokolov@postgrespro.ru>

View thread
From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Sami Imseih <samimseih@gmail.com>
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-27T05:00:28Z
Lists: pgsql-hackers 
26.02.2026 23:44, Sami Imseih пишет:
>> (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.

If there were asserts, then tests would have failed.
Period.

There would no the bug. There would no this discussion.
If only array bounds were checked with asserts.

-- 
regards
Yura Sokolov aka funny-falcon

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