| From: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
|---|---|
| To: | Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Andres Freund <andres(at)anarazel(dot)de>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Subject: | Re: Fix bug in multixact Oldest*MXactId initialization and access |
| Date: | 2026-02-28 07:43:49 |
| Message-ID: | cfea353d-585a-425c-aec7-b783f3d441d8@postgrespro.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2026-02-28 08:13:15 | Re: Skipping schema changes in publication |
| Previous Message | jian he | 2026-02-28 07:27:21 | Re: let ALTER TABLE DROP COLUMN drop whole-row referenced object |