Hi,
On Fri, Sep 04, 2026 at 10:45:11AM +0500, Kirill Reshke wrote:
> On Mon, 31 Aug 2026 at 07:39, Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> 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
