| From: | Alvaro Herrera <alvherre(at)kurilemu(dot)de> |
|---|---|
| To: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
| Cc: | pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>, Antonin Houska <ah(at)cybertec(dot)at>, mihailnikalayeu(at)gmail(dot)com |
| Subject: | Re: [PATCH] Avoid a REPACK worker startup hang |
| Date: | 2026-09-13 13:12:33 |
| Message-ID: | aqae1DPFOEy8ThRa@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
https://www.postgresql.org/message-id/flat/CALj2ACVAxA9HxvFe8HSspTJ-UO4Aoz%3DkuQdZBeLrod0gqUxH3g%40mail.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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Konstantin Knizhnik | 2026-09-13 13:30:53 | Recovery at replica stuck because recovery incorrectly trusts an old high-water mark |
| Previous Message | Álvaro Herrera | 2026-09-13 12:52:54 | Re: CLUSTER progress: wrong index_rebuild_count for tables with TOAST |