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-28T07:43:49Z
Lists: pgsql-hackers 
27.02.2026 21:51, Sami Imseih пишет:
> It's unfortunately a bit worse. Here is a repro that shows 2 prepared
> transactions
> being created after a shared lock is taken on a table with 1 row. A subsequent
> delete is able to complete, where we would expect it to be blocked until the
> prepared transactions COMMIT or ROLLBACK.

OH MY GOD!!!!
I saw very similar behavior in dump of production WAL logs from our client.
Main issue were in other subsystem in that case, that is why we didn't dig
deeper.
But I clearly remembered: "Ouch, it is strange, why this row were deleted
being locked for foreign key?".

Great catch!!!!
My deep respect to you, Sami Imseih!!!!

> With simply adding NUM_AUXILIARY_PROCS to MaxOldestSlot, it works as expected,
> and the delete is blocked.
-- 
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