Re: Dependency between bgw_notify_pid and bgw_flags
От | Robert Haas |
---|---|
Тема | Re: Dependency between bgw_notify_pid and bgw_flags |
Дата | |
Msg-id | CA+TgmoZ8Eu=r9=YaAtA8-W-R0DCf-_gpNk1gaJkNJgEroOnJXA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Dependency between bgw_notify_pid and bgw_flags (Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>) |
Ответы |
Re: Dependency between bgw_notify_pid and bgw_flags
|
Список | pgsql-hackers |
On Tue, Jul 7, 2015 at 4:34 AM, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com> wrote: > With that notion of backend, to fix the original problem I reported, > PostmasterMarkPIDForWorkerNotify() should also look at the > BackgroundWorkerList. As per the comments in the prologue of this function, > it assumes that only backends need to be notified about worker state change, > which looks too restrictive. Any backend or background worker, which wants > to be notified about a background worker it requested to be spawned, should > be allowed to do so. Yeah. I'm wondering if we should fix this problem by just insisting that all workers have an entry in BackendList. At first look, this seems like it would make the code a lot simpler and have virtually no downside. As it is, we're repeatedly reinventing new and different ways for unconnected background workers to do things that work fine in all other cases, and I don't see the point of that. I haven't really tested the attached patch - sadly, we have no testing of background workers without shared memory access in the tree - but it shows what I have in mind. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: