On Mon, 31 Aug 2026 at 07:39, Bertrand Drouvot <[email protected]> wrote: > > Hi hackers, > > While working on providing more informations related to locks (patch not > shared > yet), it appeared that pg_blocking_pids() can omit the process that is > actually > blocking a relation extension request. > > Indeed, commit 85f6b49c2c53 made relation extension locks conflict between > members > of the same parallel lock group, but did not update the same group filtering > in > pg_blocking_pids(). > > The attached adds the relation extension exception in pg_blocking_pids(). > > pg_blocking_pids() reports parallel workers using their lock group leader PID. > Therefore, when one member of a parallel lock group blocks another, the PID > supplied to pg_blocking_pids() can appear in the result. This does not mean > that a process blocks itself. Rather, a lock held by one member of its > parallel > lock group blocks a lock request made by another member of that group. The > patch > documents this behavior.
Your fix looks correct to me, matches deadlock detector code. > No regression test is added because ensuring relation extension lock > contention > between members of the same parallel lock group would be more complicated than > needed for this simple patch. Isolation test you mean? Shouldn't be that hard using injection points, but Anyway, I think I agree, too much cpu cycles will be wasted on this small issue. -- Best regards, Kirill Reshke
