Hi, On Fri, Sep 04, 2026 at 10:45:11AM +0500, Kirill Reshke wrote: > 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.
Thanks for looking at it! > > 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. Yeah, that does not seem worth it. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
