RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE - Mailing list pgsql-hackers

From Aya Iwata (Fujitsu)
Subject RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Date
Msg-id OS7PR01MB119645F36D5D4680189EA653EEAD4A@OS7PR01MB11964.jpnprd01.prod.outlook.com
Whole thread Raw
In response to RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE  ("Aya Iwata (Fujitsu)" <iwata.aya@fujitsu.com>)
List 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

pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Add mode column to pg_stat_progress_vacuum
Next
From: Andrey Silitskiy
Date:
Subject: Re: Exit walsender before confirming remote flush in logical replication