On Fri, Jul 23, 2010 at 11:58 AM, Hannu Krosing <hannu@krosing.net> wrote:
> On Thu, 2010-07-22 at 20:57 -0400, Robert Haas wrote:
>> On Thu, Jul 22, 2010 at 3:15 PM, Hannu Krosing <hannu@krosing.net> wrote:
>> > On Thu, 2010-07-22 at 14:36 -0400, Robert Haas wrote:
>> >> On Mon, Jul 12, 2010 at 6:58 AM, Craig Ringer
>> >> <craig@postnewspapers.com.au> wrote:
>> >> > So rather than asking "should core have a connection pool" perhaps
>> >> > what's needed is to ask "what can an in-core pool do that an external
>> >> > pool cannot do?"
>> >>
>> >> Avoid sending every connection through an extra hop.
>> >
>> > not really. in-core != magically-in-right-backend-process
>>
>> Well, how about if we arrange it so it IS in the right backend
>> process? I don't believe magic is required.
>
> Do you have any design in mind, how you can make it so ?
Well, if we could change the backends so that they could fully
reinitialize themselves (disconnect from a database to which they are
bound, etc.), I don't see why we couldn't use the Apache approach.
There's a danger of memory leaks but that's why Apache has
MaxRequestsPerChild, and it works pretty darn well. Of course,
passing file descriptors would be even nicer (you could pass the
connection off to a child that was already bound to the correct
database, perhaps) but has pointed out more than once, that's not
portable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
