| From: | Andrew Borodin <borodin(at)octonica(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: background sessions |
| Date: | 2016-12-15 06:54:44 |
| Message-ID: | CAJEAwVE39yZ-ko+87Tp7yOL5x=2QccQ_+fH7hhn5Jgysmd_jzA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
2016-12-15 0:30 GMT+05:00 Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>:
>>>> 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.
Agree, doing this in Python is the better option.
And one more thing... Can we have BackgroundSessionExecute() splitted
into two parts: start query and wait for results?
It would allow pg_background to reuse bgsession's code.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | amul sul | 2016-12-15 07:31:32 | Re: background sessions |
| Previous Message | Michael Paquier | 2016-12-15 06:17:57 | Re: Password identifiers, protocol aging and SCRAM protocol |