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-26T17:02:38Z
Lists: pgsql-hackers 
26.02.2026 19:34, Sami Imseih пишет:
>> But I still use inline procs for access to the arrays. Asserts cost nothing
>> in release build. And new version of functions doesn't branch.
> 
> Asserts may have minimal impact for most builds, but my concern is
> this is all unnecessary complexity. I mean if we guarantee that the
> arrays are initialized correctly, maybe we can have an assert at
> init time, why would we need asserts at run time?

They are future proof.

If there had been assertions from the beginning, there would not have been
a breaking change. The tests would have failed.

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

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