Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Дата
Msg-id 202108021808.plo7fakfyd2o@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  ("Andres Freund" <andres@anarazel.de>)
Список pgsql-hackers
On 2021-Aug-02, Tom Lane wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
> > If you're saying that this code has been 100% broken for 7 years and
> > nobody's noticed until now, then that suggests that nobody actually
> > uses non-shmem-connected bgworkers. I sort of hate to give up on that
> > concept but if we've really gone that many years without anyone
> > noticing obvious breakage then maybe we should.
> 
> Well, the problem only exists on Windows so maybe this indeed
> escaped notice.  Still, this is good evidence that the case isn't
> used *much*, and TBH I don't see many applications for it.
> I can't say I'm excited about putting effort into fixing it.

When I included this case I was thinking in tasks which would just run
stuff not directly connected to data.  Something like a sub-daemon: say
a connection pooler, which is a bgworker just so that it starts and
stops together with postmaster, and share facilities like GUC
configuration and SIGHUP handling, etc.  It doesn't look like anybody
has had an interest in developing such a thing, so if this is
obstructing your work, I don't object to removing the no-shmem case.

-- 
Álvaro Herrera           39°49'30"S 73°17'W  —  https://www.EnterpriseDB.com/



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: straightening out backend process startup
Следующее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: make MaxBackends available in _PG_init