From: Gerhard Hintermayer <g.hintermayer@inode.at>
To: pgsql-interfaces@postgresql.org
Subject: Re: still memory leaks with libpgtcl
Date: Tue, 07 Jan 2003 18:30:18 +0100
Message-ID: <avf32e$rep$1@news.hub.org> (raw)
In-Reply-To: <auj41k$f4v$1@news.hub.org>
References: <as0da6$2njk$1@news.hub.org>
<auhq8v$2iuo$1@news.hub.org>
<auj41k$f4v$1@news.hub.org>
ljb wrote:
> Sure people are using it. As I understand it: The Tcl interface included
> with PostgreSQL-7.3.1 is the preferred, production release. The new
> libpgtcl on gborg.postgresql.org is beta-test; when it is done, the Tcl
> interface will be unbundled from the PostgreSQL releases (like the perl5
> interface already is). The latest release of the unbundled libpgtcl-1.4b3
> seems pretty good to me (I was unable to break it), so I suggest you try it
> if you can.
>
OK, good to know. In the meanwhile I upgraded to 7.3.1, so 1) and 2) are OK.
> As to your specific issues:
>
> 1) The PostgreSQL-7.3.1 released libpgtcl does have the connection loss
> handling function.
>
> 2) I'm not sure what you are referring to by "fix for finding a free
> connection slot (PSetResultID)". If you mean finding a free result
> structure slot (PGSetResultID), then I see code changes there and I think
> that is fixed in both 7.3.1 and 1.4b3. It seems to work as it should: I
> can allocate 128, but not 129 result structures.
>
> 3) Memory leak on connect/disconnect unfortunately is not fixed in either
> the production or beta versions. I'm seeing about 4KB loss per
> connect/disconnect. I'm sure this is serious for some applications, but
> others would probably not have trouble here. I can't remember: was there a
> patch - has this leak been tracked down?
Definitely serious, took me a long time to find out, why two machines hat to be
hard rebooted because they ran out of memory after some weeks running with no
problems. Changed the "connect/disconnect when idle" strategy to "connect at
startup and stay so".
If I'd track down the problem and sent a patch, has the wheel to be reinvented
for gborg ? Two concurrent developments is not a good thing.
Oops, forgot to check that thread. Thanks for your response.
--
Gerhard Hintermayer
http://www.inode.at/g.hintermayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: g.hintermayer@inode.at
Subject: Re: still memory leaks with libpgtcl
In-Reply-To: <avf32e$rep$1@news.hub.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox