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