Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Дата
Msg-id 2f2fc63f-7d21-4db6-abce-18610a9497fb@www.fastmail.com
обсуждение исходный текст
Ответ на Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Список pgsql-hackers
Hi,

On Mon, Aug 2, 2021, at 12:12, Alvaro Herrera wrote:
> On 2021-Aug-02, Andres Freund wrote:
> > I do think there's some potential gains in simplicity and robustness
> > that are made mildly harder by a subprocess that first attaches and
> > detaches from shm (it's the only case where we can't easily unify the
> > place InitProcess() is called between EB and ! EB right now). There's
> > several ways that could be tackled. Removing the need to have that if
> > obviously one of them.
> 
> Hmm, I don't remember that an shmem-unconnected bgworker first connected
> to it and then let go.  It seems weird to do it that way.  My intention,
> as far as I recall, is that they would just never connect to shmem,
> period.

They currently do for EXEC_BACKEND. See SubPostmasterMain(). There the definition of the worker is passed via shared
memory.So it does the full reattach thing, which requires lwlock, which requires PGPROC. We could get away without that
bypassing more through the variables file (either the worker definition or the address of the bgworker shmem piece).
 

Greetings,

Andres



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: EXEC_BACKEND vs bgworkers without BGWORKER_SHMEM_ACCESS