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

From Peter Eisentraut
Subject Re: [HACKERS] background sessions
Date
Msg-id 477ad00e-80f8-52e7-ffc5-2377d3c59301@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] background sessions  (Andrew Borodin <borodin@octonica.com>)
Responses Re: [HACKERS] background sessions  (Andrew Borodin <borodin@octonica.com>)
List pgsql-hackers
On 12/14/16 11:33 AM, Andrew Borodin wrote:
> 2016-12-14 20:45 GMT+05:00 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>:
>> On 12/11/16 5:38 AM, Andrew Borodin wrote:
>>> 2. From my point of view the interface of the feature is the strong
>>> point here (compared to pg_background). But it does not help
>>> programmer to follow good practice: bgworker is a valuable and limited
>>> resource, may be we could start session with something like
>>> TryBeginSession()?
>>
>> What exactly would that do?
> Return status (success\failure) and session object, if a function succeeded.
> 
> If there is max_connections exceeded, then (false,null).
> 
> I'm not sure whether this idiom is common for Python.

You can catch PostgreSQL exceptions in PL/Python, so this can be handled
in user code.

Some better connection management or pooling can probably be built on
top of the primitives later, I'd say.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: [HACKERS] Linear vs. nonlinear planner cost estimates
Next
From: Heikki Linnakangas
Date:
Subject: Re: pg_authid.rolpassword format (was Re: [HACKERS] Password identifiers, protocol aging and SCRAM protocol)