Re: Parallel autovacuum: leader crashes when no DSM segment can be created

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

In response to

Browse pgsql-hackers by date

  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