Re: background sessions

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

In response to

Responses

Browse pgsql-hackers by date

  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