| 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
| 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 |