From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | amborodin(at)acm(dot)org |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: background sessions |
Date: | 2016-12-14 19:30:14 |
Message-ID: | 477ad00e-80f8-52e7-ffc5-2377d3c59301@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 12/14/16 11:33 AM, Andrew Borodin wrote:
> 2016-12-14 20:45 GMT+05:00 Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2016-12-14 19:34:55 | Re: pg_authid.rolpassword format (was Re: Password identifiers, protocol aging and SCRAM protocol) |
Previous Message | Tom Lane | 2016-12-14 19:12:40 | Linear vs. nonlinear planner cost estimates |