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

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: 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-09-30 02:45:00
Message-ID: CALj2ACWeWm6BMHf6tk0f+sKW5N0UEjN6L19yrUFTS+2MhH3i0g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Mon, Sep 28, 2026 at 11:39 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> Thank you for the report and the patch!

Thanks for taking a look at it.

> IIUC the issue stems from the fact that the leader and its workers
> advertise different roleIds (InvalidOid and BOOTSTRAP_SUPERUSERID). I
> think the same issue can be reproduced in other cases. For instance,
> suppose that a bgworker connecting to the database via
> BackgroundWorkerInitializeConnection(dbname, NULL, 0) runs a parallel
> query, the leader's roleId is InvalidOid whereas the parallel query
> workers have BOOTSTRAP_SUPERUSERID. I think we should fix it as well
> and backpatch the fix to 14.

Good catch. Yes, it happens there too. I verified it locally with a
simple test module that launches a background worker and starts a
parallel worker to run a query. I agree the fix needs to be
back-patched through 14.

> I have some review comments on the proposed patch:
>
> + if (leader != NULL && leader != proc &&
> + leader->backendType == B_AUTOVAC_WORKER)
> + roleId = InvalidOid;
>
> I think we should check a lock group member with its leader's roleId
> instead of unconditionally using InvalidOid. That would
> straightforwardly fix the inconsistency between the leader and the
> workers.
>
> if (leader != NULL && leader != proc &&
> leader->databaseId == databaseId)
> roleId = leader->roleId;
>
> To fix this issue not only in autovacuum cases, the backendType check
> should be removed.

Agreed, that is better. Checking a parallel worker against its
leader's roleId is the right choice here, since both are members of
the same lock group. It gives the expected behavior, terminating both
the leader and the workers for DROP DATABASE FORCE, which both run as
the bootstrap superuser.

Please find the attached v2 patch. I plan to share patches for the
back branches without the TAP test for branches < PG19 unless there
are any comments.

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v2-0001-Fix-DROP-DATABASE-FORCE-to-terminate-parallel-wor.patch application/octet-stream 7.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2026-09-30 02:47:57 Re: Assert failure in get_baserel_parampathinfo with lateral UNION ALL
Previous Message Ayush Tiwari 2026-09-30 02:23:12 Re: [PATCH] Clear FatalError earlier during crash restart