Query stuck with wait event IPC / ParallelFinish
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.
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:t72422psql -h localhost -U postgresBuilt from patchset v1 (message #1), October 06, 2026 at 07:58 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 t72422_1 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 t72422_1 && git checkout t72422_1Patchset v1 (message #1) is on t72422_1
If the attached test patch is applied (no code changes) to master, and
the "amcheck" target is run with debug_parallel_query = regress, I see
the following stuck query:
# select
application_name,
now() - state_change AS duration,
wait_event_type,
wait_event,
state,
query
from pg_stat_activity
where pid<>pg_backend_pid() and backend_type='client backend';
application_name | 004_verify_nbtree_unique.pl
duration | 00:12:29.456255
wait_event_type | IPC
wait_event | ParallelFinish
state | active
query | DELETE FROM bttest_unique3 WHERE 380 <= i
AND i <= 420;
I found this while fixing a parallel query problem with 2af07e2f74, but
the problem can be observed on an earlier version of master as well
(2c29e7fc95) so it's unrelated to my change.
I haven't investigated much, but I don't see an explanation other than
a bug. It reproduces on my local machine consistently.
Regards,
Jeff Davis