| From: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Parallel autovacuum: leader crashes when no DSM segment can be created |
| Date: | 2026-09-30 10:08:11 |
| Message-ID: | CAJTYsWVvGOGmyXVjjOwC4-R31Lp1iay27jR5tukr+CTh2JefMA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
I wonder if we should also back out of parallel_vacuum_init() when
pcxt->seg is NULL, like the parallel index builds do.
AFAICS, we otherwise go on to TidStoreCreateShared(), which needs
another DSM segment. That seems to defeat the leader-only fallback
when DSM slots stay exhausted. On master, with another session holding
every DSM slot, VACUUM (PARALLEL 2) fails with "too many dynamic shared
memory segments", while VACUUM (PARALLEL 0) succeeds.
The attached patch returns NULL there, letting the caller use a local
TidStore, and drops the nworkers check from cc053b6e127, which I think
becomes redundant?
Am I missing a reason to keep the shared TidStore in the no-worker case?
Regards,
Ayush
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fall-back-to-serial-vacuum-when-out-of-DSM-segmen.patch | application/octet-stream | 2.9 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Sharma | 2026-09-30 10:20:30 | Re: Persist slot invalidations before publishing them |
| Previous Message | Rahul Yadav | 2026-09-30 10:07:26 | Re: BUG #19599: RestoreBlockImage: the decode cross-checks never bound hole_offset + hole_length against BLCKSZ |