From: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Built-in connection pooling |
Date: | 2018-04-18 13:31:01 |
Message-ID: | b76a2af5-a293-9916-6eae-dd339b89cb8e@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 18.04.2018 16:09, Craig Ringer wrote:
> On 18 April 2018 at 19:52, Konstantin Knizhnik
> <k(dot)knizhnik(at)postgrespro(dot)ru> wrote:
>
>> As far as I know most of DBMSes have some kind of internal connection
>> pooling.
>> Oracle, for example, you can create dedicated and non-dedicated backends.
>> I wonder why we do not want to have something similar in Postgres.
> I want to, and I know many others to.
>
> But the entire PostgreSQL architecture makes it hard to do well, and
> means it requires heavy changes to do it in a way that will be
> maintainable and reliable.
>
> Making it work, and making something maintainble and mergeable, are
> two different things. Something I continue to struggle with myself.
>
Here I completely agree with you.
Now my prototype "works": it is able to correctly handle errors,
transaction rollbacks, long living transactions,... but I am completely
sure that there are a lot of not tested cases when it will work
incorrectly. But still I do not think that making built-in connection
pooling really reliable is something unreachable.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2018-04-18 13:36:46 | Re: Built-in connection pooling |
Previous Message | David Fetter | 2018-04-18 13:24:52 | Re: Built-in connection pooling |