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

Поиск
Список
Период
Сортировка
От Aya Iwata (Fujitsu)
Тема RE: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE
Дата
Msg-id OS7PR01MB11964D713C79B209EFF6A024CEAB2A@OS7PR01MB11964.jpnprd01.prod.outlook.com
обсуждение исходный текст
Ответ на Re: [PROPOSAL] Termination of Background Workers for ALTER/DROP DATABASE  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Hi

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

I'm sorry for the delayed response.
I tried implementing a callback function within the for loop to allow setting the termination
condition myself. However, I felt this method had few use-cases. Since LWlock exists in here, it can
only handle lightweight operations.
Therefore, I'd prefer not to include it at this time. If I later think of a useful scenario for it, I'll
reconsider about this.

Best Regards,
Aya Iwata



В списке pgsql-hackers по дате отправления: