pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Sami Imseih <samimseih@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Andres Freund <andres@anarazel.de>
Cc: Chao Li <li.evan.chao@gmail.com>
Subject: Re: Fix bug in multixact Oldest*MXactId initialization and access
Date: Sat, 28 Feb 2026 10:43:49 +0300
Message-ID: <cfea353d-585a-425c-aec7-b783f3d441d8@postgrespro.ru> (raw)
In-Reply-To: <CAA5RZ0twq5bNMq0r0QNoopQnAEv+J3qJNCrLs7HVqTEntBhJ=g@mail.gmail.com>
References: <7acc94b0-ea82-4657-b1b0-77842cb7a60c@postgrespro.ru>
	<93F0BD0A-0B8B-4592-9D4B-53F405A86F6A@gmail.com>
	<c3eaaac1-d244-4e4d-b5d7-06c284108eac@postgrespro.ru>
	<C991344D-F38A-4EEC-903A-72B52FF887FA@gmail.com>
	<bf2951b4-687b-4bd3-a072-46deb463f177@postgrespro.ru>
	<CAA5RZ0t8iGnqO3JcAZP1VEjCspcnZtQ0GFFVGLNLAsFqfHqRsw@mail.gmail.com>
	<ebeb0db1-0eb2-4439-a6c8-1d96b60b25ad@postgrespro.ru>
	<CAA5RZ0s+rr=DVkFnMwupgnCAvPjJkjQ3jr5=7X_=Sb5Mr02-Mg@mail.gmail.com>
	<3d7a2207-0e61-4d95-bc00-e5248956a32b@postgrespro.ru>
	<366b6f95-613d-4ef8-82e4-bb2fd06d9c4d@iki.fi>
	<cac03ce7-b5b9-46d7-8127-a827812230ce@postgrespro.ru>
	<CAA5RZ0twq5bNMq0r0QNoopQnAEv+J3qJNCrLs7HVqTEntBhJ=g@mail.gmail.com>

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





view thread (31+ messages)  latest in thread

Message-ID: <cfea353d-585a-425c-aec7-b783f3d441d8@postgrespro.ru>
Permalink:  ../cfea353d-585a-425c-aec7-b783f3d441d8@postgrespro.ru/
Also on:    postgresql.org/message-id/cfea353d-585a-425c-aec7-b783f3d441d8@postgrespro.ru

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: y.sokolov@postgrespro.ru, samimseih@gmail.com, pgsql-hackers@lists.postgresql.org, hlinnaka@iki.fi, andres@anarazel.de, li.evan.chao@gmail.com
  Subject: Re: Fix bug in multixact Oldest*MXactId initialization and access
  In-Reply-To: <cfea353d-585a-425c-aec7-b783f3d441d8@postgrespro.ru>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox