Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers
Date
Msg-id CAD21AoBo=Gd0qXXvOmZzPiBdQ0FiCxJHO_jOSxQXgCgDxYcwxA@mail.gmail.com
Whole thread
In response to Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers  (shihao zhong <zhong950419@gmail.com>)
Responses Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers
List pgsql-hackers
On Sun, Oct 4, 2026 at 8:35 PM shihao zhong <zhong950419@gmail.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



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers
Next
From: shihao zhong
Date:
Subject: Re: [PG19] plpgsql: SELECT INTO sets FOUND wrongly after a function becomes a SRF