Report relation extension blockers within parallel lock groups
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
This thread has been committed, so CI has stopped here. Anything below is the last result it produced.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253613psql -h localhost -U postgresBuilt from patchset v10 (message #10), October 05, 2026 at 06:36 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253613_10 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253613_10 && git checkout t253613_10Patchset v10 (message #10) is on t253613_10
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
On Aug 31, 2026, at 10: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.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/
Hi,
On Mon, Aug 31, 2026 at 05:22:20PM +0800, Chao Li wrote:
On Aug 31, 2026, at 10:39, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
Looks like 3ba59ccc896e did the same thing for page locks,
Right, but 3ba59ccc896e was reverted by cc32ec24fdf (and backpatched through 13).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
On Aug 31, 2026, at 18:38, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
Hi,
On Mon, Aug 31, 2026 at 05:22:20PM +0800, Chao Li wrote:
On Aug 31, 2026, at 10:39, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
Looks like 3ba59ccc896e did the same thing for page locks,
Right, but 3ba59ccc896e was reverted by cc32ec24fdf (and backpatched through 13).
Ah, then sorry for the noise.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
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.
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
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
On 4 Sep 2026, at 10:45, Kirill Reshke <reshkekirill@gmail.com> wrote:
Your fix looks correct to me, matches deadlock detector code.
Do you think CF entry [0]https://commitfest.postgresql.org/patch/7228/ should be marked RfC?
Best regards, Andrey Borodin.
The description in the documentation is getting quite dense. This could be
a good opportunity to restructure it for readability.
--
nathan
Hi Bertrand,
I reviewed and tested v1. The code change looks good to me.
The description in the documentation is getting quite dense. This could
be
a good opportunity to restructure it for readability.
The attached 0002 goes on top of v1.
It moves the prepared transaction sentence up and
gives parallel query its own paragraph.
Thanks,
Shihao
Attachments:
nocfbot-0002-Restructure-pg_blocking_pids-documentation.patchapplication/octet-stream; name=nocfbot-0002-Restructure-pg_blocking_pids-documentation.patchDownload+14-16
Hi Shihao,
On Fri, Oct 02, 2026 at 10:47:03PM -0600, shihao zhong wrote:
Hi Bertrand,
The description in the documentation is getting quite dense. This could
be
a good opportunity to restructure it for readability.
The attached 0002 goes on top of v1.
It moves the prepared transaction sentence up and
gives parallel query its own paragraph.
Thanks for the proposal!
Moving the prepared transaction sentence up and giving parallel query its own
paragraph make sense to me. That said, I think that the parallel query paragraph
could be made a bit shorter like in v2 attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Attachments:
t253613_10v2-0001-Report-relation-extension-blockers-within-paralle.patchtext/x-diff; charset=us-asciiDownload+21-10
Hi Bertrand,
I think this patch is LGTM!
Set the state to `Ready for Committer`
Thanks,
Shihao