Re: Backend connection pooling memleak - Mailing list pgsql-general

From Martijn van Oosterhout
Subject Re: Backend connection pooling memleak
Date
Msg-id 20051102142341.GD19550@svana.org
Whole thread Raw
In response to Backend connection pooling memleak  ("Mike Shelton" <pgsql4mjs@cableone.net>)
List pgsql-general
On Tue, Nov 01, 2005 at 11:33:39PM -0700, Mike Shelton wrote:
> Hello,
>
> I implemented connection pooling in the backend of postgresql (one of the
> TODO items) and I've found some really interesting performance improvements
> I'd like to continue to explore but unfortunately I've also uncovered a
> nasty little side effect with the memory usage.  It's my guess that it's
> either a number of mallocs don't have corresponding frees because the
> process would exit when the transaction is done (normally) or I've bypassed
> some of the memory context "free"s that would have also resulted in memory
> being reclaimed on a process exit or more importantly on a connection being
> reclosed.

You should probably look at the memory management documentation. Many
(most?) pmallocs are not explicitly freed. Instead, the context they
are allocated in is either reset or freed. So in your case, it should
simply be a matter of resetting some of the nearly top level contexts.

See src/backend/utils/mmgr/README

> The implementation was done on 7.3.4.  It was the latest at the time I
> started and I haven't sync'd up yet because I wasn't sure if there would be
> a need in terms of the general postgresql population wanting this feature.
> If the improvements prove to be real and generalized versus specialized
> (just a few use cases for example) then I would imagine the interest would
> grow but I'm not there yet.

The question is, are the improvements worth the costs? What does your
implementation do that something like pgpool doesn't?

Good luck.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Attachment

pgsql-general by date:

Previous
From: "Dave Page"
Date:
Subject: Re: [ANNOUNCE] PostgreSQL 8.1.0 Release Candidate 1
Next
From: Ian Harding
Date:
Subject: Re: Oracle 10g Express - any danger for Postgres?