[PATCH] Avoid a REPACK worker startup hang
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:t253776psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 17, 2026 at 10:30 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 t253776_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 t253776_1 && git checkout t253776_1Patchset v1 (message #1) is on t253776_1
Hi hackers,
On REL_19_STABLE at 6bc236c8, my automated (AI) harness reproduced a
worker startup failure 3/3 times in each of two clusters. Start a
disposable postmaster with a low RLIMIT_NPROC, open the leader connection,
exceed that limit with same-UID helper processes, then run
`repack (concurrently) t`.
The postmaster logs `could not fork background worker process: Resource
temporarily unavailable`. No worker starts, and the leader remains in
IPC/RepackWorkerExport until an external statement_timeout; without one it
has no internal exit. The condition-variable wait consumes the latch wake
reporting the worker-state change.
The attached patch waits directly on the latch, checks the worker handle,
reports an initialization error if it stopped, and preserves queued errors.
The injection test covers failure before DSM attachment and after queue
attachment, unchanged storage, and same-backend retry.
Assertions/injection-points build: 14/14 isolation, 4/4 injection
regression, 240/240 core regression.
I haven't spent much time reviewing this manually: I'm testing several PG19
areas in parallel. The harness tested this thoroughly, but I'd appreciate a
look from people who worked on this. If it doesn't make sense, please let
me know; I'll exclude it from scope.
Attached: 0001-repack-worker-startup.patch
Nik
On 2026-Sep-13, Nikolay Samokhvalov wrote:
Hi hackers,
On REL_19_STABLE at 6bc236c8, my automated (AI) harness reproduced a
worker startup failure 3/3 times in each of two clusters. Start a
disposable postmaster with a low RLIMIT_NPROC, open the leader connection,
exceed that limit with same-UID helper processes, then run
`repack (concurrently) t`.The postmaster logs `could not fork background worker process: Resource
temporarily unavailable`.
Hmm, this sounds related to the report here
/messages/by-id/CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz=kuQdZBeLrod0gqUxH3g@mail.gmail.com
I tried your isolation test against Bharath's patch, and I see that the
error condition is reported correctly. I haven't reviewed that patch.
I'll review that for push, maybe together with your proposed test
addition.
Thanks!
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
On Sun, Sep 13, 2026 at 6:12 AM Alvaro Herrera
<alvherre@kurilemu.de> wrote:
I tried your isolation test against Bharath's patch, and I see that the
error condition is reported correctly. I haven't reviewed that patch.
I'll review that for push, maybe together with your proposed test
addition.
I tested v4 further and followed up in that thread about the remaining
post-attachment waits:
/messages/by-id/CAM527d8cF-6azsRWOPaOUCmsdgMG=ene7-st91_NM7v0q3uLLg@mail.gmail.com
Nik