Re: [HACKERS] background sessions

Поиск
Список
Период
Сортировка
От Andrew Borodin
Тема Re: [HACKERS] background sessions
Дата
Msg-id CAJEAwVEOqj-EFh68+-dasL1JgM=6JWqEjhjh8WCOtbKpX_azEg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] background sessions  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Ответы Re: [HACKERS] background sessions  (amul sul <sulamul@gmail.com>)
Список pgsql-hackers
2017-01-03 19:39 GMT+05:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
On 1/3/17 1:26 AM, amul sul wrote:
> One more requirement for pg_background is session, command_qh,
> response_qh and worker_handle should be last longer than current
> memory context, for that we might need to allocate these in
> TopMemoryContext.  Please find attach patch does the same change in
> BackgroundSessionStart().

I had pondered this issue extensively.  The standard coding convention
in postgres is that the caller sets the memory context.  See the dblink
and plpython patches that make this happen in their own way.

I agree it would make sense that you either pass in a memory context or
always use TopMemoryContext.  I'm open to these ideas, but they did not
seem to match any existing usage.
+1
Please excuse me if I'm not getting something obvious, but seems like BackgroundSessionNew() caller from pg_background_launch() can pick up TopMemoryCtx. I think that context setup should be done by extension, not by bg_session API.

Best regards, Andrey Borodin.

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Update copyright for 2017
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [COMMITTERS] pgsql: Update copyright for 2017