| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Cc: | Masahiko Sawada <sawada(dot)mshk(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-10-23 00:51:34 |
| Message-ID: | CALj2ACUO8CFQoN9PRenxiuYHXE1hVBHd2_OqHvEUagXO-C-VdQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Wed, Sep 30, 2026 at 3:08 AM Ayush Tiwari
<ayushtiwari(dot)slg01(at)gmail(dot)com> wrote:
>
> I wonder if we should also back out of parallel_vacuum_init() when
> pcxt->seg is NULL, like the parallel index builds do.
I don't think falling back to non-parallel vacuum only when the
parallel context DSM creation fails is the right approach. For
instance, the parallel context could be created successfully, and then
later either the first or a subsequent dead-TID DSM allocation could
fail and still hit the too many DSM segments error. I don't see a
clean way to handle such cases. Since it can error out anyway, I think
failing the vacuum in these cases is fine.
The segv fixed in cc053b6e127 seems fine to me, because
InitializeParallelDSM() expects callers to work with no workers when
it detects that no DSM could be allocated.
That said, others may have different thoughts, so +1 to continuing to
pursue this for HEAD.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Chao Li | 2026-10-23 00:52:40 | Re: Parallel vacuum: workers together with leader could overrun cost budget |
| Previous Message | Koshino Taiki | 2026-10-23 00:50:48 | Proposal: Include CHECK constraint expression in violation error DETAIL |