X-Original-To: pgsql-interfaces@postgresql.org Received: from spampd.localdomain (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 29BDC475AA9 for ; Sat, 12 Apr 2003 11:10:36 -0400 (EDT) Received: from sabre.velocet.net (sabre.velocet.net [216.138.209.205]) by postgresql.org (Postfix) with ESMTP id 945B647580B for ; Sat, 12 Apr 2003 11:10:35 -0400 (EDT) Received: from stark.dyndns.tv (H162.C233.tor.velocet.net [216.138.233.162]) by sabre.velocet.net (Postfix) with ESMTP id 25B5F1383B7; Sat, 12 Apr 2003 11:10:46 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=stark.dyndns.tv ident=foobar) by stark.dyndns.tv with smtp (Exim 3.36 #1 (Debian)) id 194MeQ-0000aV-00; Sat, 12 Apr 2003 11:10:42 -0400 To: Tom Lane Cc: "P.N.Guru Prasad" , pgsql-interfaces@postgresql.org Subject: Re: Memory leak!! References: <4468.1049864296@sss.pgh.pa.us> In-Reply-To: <4468.1049864296@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 Date: 12 Apr 2003 11:10:42 -0400 Message-ID: <87ptnriwel.fsf@stark.dyndns.tv> Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-38.8 required=5.0 tests=BAYES_01,EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_GNUS_UA autolearn=ham version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Archive-Number: 200304/107 X-Sequence-Number: 4046 Tom Lane writes: > "P.N.Guru Prasad" writes: > > while (1) { > > print "sql executed and returned :", $Dbh->prepare("select user_id from > > users limit 1")->execute, "\n"; > > } > > I'm not a DBI user, but I'd kinda expect that executing a query would > result in an object holding the results from that query. Don't you need > to do something to close/delete the result objects you're generating? Perl reference counts these objects so that shouldn't be a problem. You could be sure by using Devel::LeakTrace or Devel::Leak or something like that. But I suspect they won't find anything because I suspect the problem is in the DBD::pg driver or libpq at the C level. -- greg