Re: Report relation extension blockers within parallel lock groups

On Mon, 31 Aug 2026 at 07:39, Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)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.

> 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