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 по дате отправления: