RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE

From: "Aya Iwata (Fujitsu)" <iwata(dot)aya(at)fujitsu(dot)com>
To: 'Peter Smith' <smithpb2250(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Date: 2025-11-20 06:57:47
Message-ID: OS7PR01MB119645F36D5D4680189EA653EEAD4A@OS7PR01MB11964.jpnprd01.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

Perhaps you haven't seen my previous post.

> > FWIW, while reading this code, I was wondering about one improvement
> > that could show benefits for more extension code than only what we are
> > discussing here because external code has no access to
> > BackgroundWorkerSlot while holding the LWLock BackgroundWorkerLock in
> > a single loop, by rewriting this new routine with something like that:
> > void TerminateBackgroundWorkerMatchin(
> > bool (*do_terminate) (int pid, BackgroundWorker *, Datum))
> >
> > Then the per-database termination would be a custom routine, defined
> > also in bgworker.c. Other extension code could define their own
> > filtering callback routine. Just an idea in passing, to let extension
> > code take more actions on bgworker slots in use-based on a PGPROC
> > entry, like a role ID for example, or it could be a different factor.
> > Feel free to dislike such a funky idea if you do not like it and say
> > so, of course.
>
> Thank you for your advice.
> I'd like to address that, but I couldn't figure out how to do it on my own.
> Could you please describe it more?

I'd like to adapt the patch for this, so could you tell me with the details?

Regards,
Aya Iwata
Fujitsu Limited

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey Silitskiy 2025-11-20 07:05:05 Re: Exit walsender before confirming remote flush in logical replication
Previous Message Robert Treat 2025-11-20 06:56:54 Re: Add mode column to pg_stat_progress_vacuum