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
