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
0001-repack-worker-startup.patch
Description: Binary data
