Re: [HACKERS] background sessions - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] background sessions
Date
Msg-id bb7e3dc1-1cf9-a538-c883-0fe60ad14f68@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] background sessions  (amul sul <sulamul@gmail.com>)
Responses Re: [HACKERS] background sessions  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
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.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] proposal: session server side variables