> On Aug 31, 2026, at 10: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.
>
> 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.
>
> Regards,
>
> --
> Bertrand Drouvot
> PostgreSQL Contributors Team
> RDS Open Source Databases
> Amazon Web Services: https://aws.amazon.com
> <v1-0001-Report-relation-extension-blockers-within-paralle.patch>
Looks like 3ba59ccc896e did the same thing for page locks, so I wonder if this
patch should include page lock as well, something like:
```
if (instance->leaderPid == blocked_instance->leaderPid &&
blocked_instance->locktag.locktag_type != LOCKTAG_RELATION_EXTEND &&
blocked_instance->locktag.locktag_type != LOCKTAG_PAGE)
continue;
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
