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
