Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id B47294772E0 for ; Tue, 7 Jan 2003 12:34:55 -0500 (EST) Received: from news.hub.org (news.hub.org [64.49.215.80]) by postgresql.org (Postfix) with ESMTP id 1E3DD4771B4 for ; Tue, 7 Jan 2003 12:34:08 -0500 (EST) Received: by news.hub.org (Postfix, from userid 8) id 1068F43B026; Tue, 7 Jan 2003 12:34:08 -0500 (EST) From: Gerhard Hintermayer X-Newsgroups: comp.databases.postgresql.interfaces Subject: Re: still memory leaks with libpgtcl Date: Tue, 07 Jan 2003 18:30:18 +0100 Organization: Hub.Org Networking Services (http://www.hub.org) Lines: 43 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en In-Reply-To: To: pgsql-interfaces@postgresql.org X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200301/27 X-Sequence-Number: 3527 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