Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: shihao zhong <zhong950419(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: DROP DATABASE WITH (FORCE) fails on the parallel workers
Date: 2026-10-06 00:36:08
Message-ID: CAD21AoBo=Gd0qXXvOmZzPiBdQ0FiCxJHO_jOSxQXgCgDxYcwxA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Oct 4, 2026 at 8:35 PM shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> Hi Bharath,
>
> v2 looks right. The new test fails without your change
> and passes with it. Attached v3 is only a rebase over head.
>
> A superuser's parallel worker is still refused, other role cases
> did not change.
>
> The check also covers the REPACK decoding worker, which connects as
> the table owner.

Right. A similar issue could happen also in REPACK workers; if DROP
DATABASE FORCE sees the repack worker and a SIGTERM arrives there
before it creates a logical slot, we would see different roles in the
leader and the worker and possibly fail. But it's unlikely to happen
in practice as it's a very short window. I'm personally okay with
covering this case but others think differently that this fix should
deal with parallel autovacuum and bgworker cases. If so, we should add
!OidIsValid(leader->roleId) to the check.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message shihao zhong 2026-10-06 00:43:07 Re: [PG19] plpgsql: SELECT INTO sets FOUND wrongly after a function becomes a SRF
Previous Message Masahiko Sawada 2026-10-06 00:27:03 Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers