[PATCH] Discard aborted updaters when expanding a multixact

Hi,

Since v1 no longer applied cleanly due to a conflict, I rebased it onto current master at fcc0e27f45e. Attached is v2.

Regards,
Chee Wooson

Hi,

Attached is v3, rebased onto master at fcc0e27f45e2d8dc6046435908a48626c91d3d84.

The v2 change in MultiXactIdExpand() fixes the two-updater ERROR, but
I found a case it cannot reach. T1 performs a non-key update while T2
takes a compatible FOR KEY SHARE lock and prepares its transaction.
The server then crashes before T1 commits. After recovery, T1's update
has not committed and the original row is still visible. However, a
REPEATABLE READ update by T3 gets "could not serialize access due to
concurrent update": TransactionIdDidAbort(T1) is false because the
crashed updater has no abort record, so heap_update() returns TM_Updated
before MultiXactIdExpand() is reached. Filtering members in Expand
cannot fix this result.

Patch 0001 addresses the original abort-window race at its earlier
conflict check: an updater is skipped only when it is no longer in
progress and did not commit. A conflicting operation therefore waits
until the abort finishes. MultiXactIdExpand()'s existing filter then
discards the aborted member, so the v2 change there is no longer needed.

heap_update() has a similar problem in its own updater-status check.
Like the conflict check changed by patch 0001, it uses
TransactionIdDidAbort(), which cannot identify an updater that crashed
without recording an abort. Such an updater is no longer running and
never committed, but TransactionIdDidAbort() still returns false.

Patch 0001 skips that updater when checking conflicts, but does not fix
heap_update()'s subsequent decision. The surviving prepared locker
makes HeapTupleSatisfiesUpdate() return TM_BeingModified, so
heap_update() still reaches its own updater-status check. Its
can_continue flag remains false and it reports TM_Updated for an update
that never committed. This causes the REPEATABLE READ error above and
can also trigger the executor's tmfd.traversed assertion at READ
COMMITTED.

Patch 0002 changes that heap_update() check to !TransactionIdDidCommit(),
after the updater has been established as no longer running.

I also checked the MultiXact-related TransactionIdDidAbort()/
TransactionIdDidCommit() calls for missing TransactionIdIsInProgress()
checks or equivalent completion guarantees, leaving
heap_lock_updated_tuple_rec() as the only remaining case to examine.

In this function, TransactionIdDidAbort() checks the successor's xmin.
An explicit abort correctly stops the chain walk. If the creator
crashed without an abort record, the walk can instead lock a dead
successor and generate extra WAL. In the cases analyzed and reproduced,
the live predecessor was still locked correctly, and subsequent updates
and pruning handled the dead successor correctly. I found no
user-visible correctness issue in those cases, so I have left this
path unchanged in v3.

Patch 0003 adds an isolation test for the abort-window race and a
recovery test for heap_update()'s crashed-updater case.

I ran the isolation test with assertions and injection points enabled on
fcc0e27f45e2d8dc6046435908a48626c91d3d84. All four permutations passed.
With only the v2 MultiXactIdExpand() change, the DELETE and key-changing
UPDATE cases reproduce assertion failures.

Regards,
Chee Wooson

Hi,

Since v3 no longer applied cleanly due to conflicts, I rebased it onto current master at 061065e28f0. Attached is v4.

Regards,
Chee Wooson

On 08/10/2026 12:04, Chee Wooson wrote:

Hi,

Since v3 no longer applied cleanly due to conflicts, I rebased it onto current master at 061065e28f0. Attached is v4.

Thanks, the fix looks correct to me.

I spend some time rewriting all the comments; I found them pretty
difficult to read. Notable, they used many words to explain that a
transaction might not be marked as committed or aborted but we have
already checked that it is not running hence it cannot commit in the
future. While that's all true, I think it's still OK, and more
understandable to a human, to just call it an "aborted transaction", or
"aborted (or crashed) transaction" if you want to call out crashed
transactions separately. That's a concept that's explained in more
detail in existing comments in heapam_visibility.c.

See attached version with my comment changes.

- Heikki

Hi Heikki,
Thanks for reviewing and revising the comments. I reviewed v5, and it looks good to me.
Regards,
Chee Wooson

Hi,

I ran into "new multixact has more than one updating member" while load
testing a trigger-based extension, and found this thread. In case it
helps with committing and back-patching, here is a plain-SQL reproducer
that needs no injection points and no crash, at READ COMMITTED with
default settings.

Schema:

CREATE TABLE tb_user (pk_user bigint PRIMARY KEY, name text);
CREATE TABLE tb_post (pk_post bigserial PRIMARY KEY,
fk_user bigint NOT NULL REFERENCES tb_user,
title text);
INSERT INTO tb_user SELECT g, 'u' FROM generate_series(1, 10) g;

ins.pgb (the FK check takes FOR KEY SHARE on the parent):

\set u random(1, 10)
INSERT INTO tb_post (fk_user, title) VALUES (:u, 't');

ren.pgb (a non-key update of the parent that always rolls back):

\set u random(1, 10)
BEGIN;
UPDATE tb_user SET name = md5(random()::text) WHERE pk_user = :u;
ROLLBACK;

pgbench -n -c 48 -j 8 -T 30 -f ins.pgb@8 -f ren.pgb@2

On REL_18_STABLE (a85b552), 24 cores, 43 of the 48 clients failed with
"ERROR: new multixact has more than one updating member" within 30
seconds, in each of three runs. With the heapam.c and xact.c changes of
v5 applied to the same tree: no errors over about 16 million
transactions in three runs, and no other errors. I also hit it on 18.1
and 18.4 under REPEATABLE READ.

Tested-by: Lionel Hamayon <lionel.hamayon@evolution-digitale.fr>

Regards,

Lionel

Hi,

Thanks for testing this and for the simple SQL reproducer!

I also reproduced this issue under TPC-C workloads without using
injection points. It's nice to have a smaller, self-contained
reproducer that makes the issue easier to investigate and verify.

The results with v5 are encouraging. The reproductions on 18.1 and
18.4 also confirm that released versions are affected, which will help
make the case for back-patching once the fix is committed.

Regards,
Chee Wooson

On 13/10/2026 04:47, Chee Wooson wrote:

Hi,

Thanks for testing this and for the simple SQL reproducer!

+1

I also reproduced this issue under TPC-C workloads without using
injection points. It's nice to have a smaller, self-contained
reproducer that makes the issue easier to investigate and verify.

The results with v5 are encouraging. The reproductions on 18.1 and
18.4 also confirm that released versions are affected, which will help
make the case for back-patching once the fix is committed.

Ok, committed and backported to all supported versions. Thanks!

- Heikki