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

On Fri, Oct 9, 2026 at 10:44 AM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> Hi,
>
> On Thu, Oct 8, 2026 at 10:52 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > > Yes, that's correct with the v2 patch. If we were to fix it for
> > > parallel workers started by any bg worker (which I think we should),
> > > the fix also needs to be back-patched. If agreed, I will check how far
> > > back it needs to be back-patched and prepare patches.
> >
> > I'd fix it only in v19 for now. While the problem exists in the back
> > branches too, it has never been reported in the field. Also the next
> > minor release will be the final one for v14, there would be no chance
> > to fix it there if this change turned out to be wrong. I think that If
> > we get a report in the future, we can backpatch it.
>
> Agreed.
>
> > Fine with me. But probably can we remove leader->databaseId ==
> > databaseId check? It seems redundant for parallel workers.
>
> That's correct, but I would like to be more cautious here, so I
> retained it. I also added a check that the parallel worker's
> advertised role is the bootstrap superuser, again to be more cautious.

Hmm, I don't think these checks narrow the case. When the leader
advertises no role, it goes through
InitializeSessionUserIdStandalone(), so its parallel workers always
run as the bootstrap superuser and connect to the same database. So
both checks are always true once !OidIsValid(leader->roleId) holds.
Even if a worker advertised another role, I think judging it by its
leader would still be fine, since we accept terminating the leader and
the worker exits with it anyway. So I'd prefer to remove both checks,
as they make readers think when they could be false.

Also, regarding the following documentation change:

- This terminates background worker connections and connections that the
- current user has permission to terminate
+ This terminates background worker connections, the parallel workers they
+ launch, and connections that the current user has permission to terminate

I think we don't need this change as parallel workers are background
workers, no?

Regards,

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