X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id E6E4E9FA5BE for ; Thu, 15 Jun 2006 13:57:41 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 19503-09 for ; Thu, 15 Jun 2006 13:57:35 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id EF1249FA13E for ; Thu, 15 Jun 2006 13:57:32 -0300 (ADT) Received: mir3-fs.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes.mirlogic.com by mir3-fs.mir3.com; 15 Jun 2006 09:57:25 -0700 Subject: Re: Postgres consuming way too much memory??? From: Mark Lewis To: Tom Lane Cc: jody brownell , pgsql-performance@postgresql.org In-Reply-To: <28321.1150385679@sss.pgh.pa.us> References: <200606141618.37849.jody.brownell@q1labs.com> <200606150901.19201.jody.brownell@q1labs.com> <200606150915.10306.jody.brownell@q1labs.com> <200606151202.50939.jody.brownell@q1labs.com> <28321.1150385679@sss.pgh.pa.us> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Thu, 15 Jun 2006 09:57:25 -0700 Message-Id: <1150390645.31200.53.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/313 X-Sequence-Number: 19670 On Thu, 2006-06-15 at 11:34 -0400, Tom Lane wrote: > "jody brownell" writes: > > When postgresql starts to go into this bloating state, I can only make it happen from my java app. > > That's interesting. The JDBC driver uses protocol features that aren't > used by psql, so it's possible that the leak is triggered by one of > those features. I wouldn't worry too much about duplicating the problem > from psql anyway --- a Java test case will do fine. > > > I am going to try closing the connection after each TX to see if this > > resolves it for now. If not, I will write a java app, stored procedure > > (table etc) reproduce it without our application. Just to mention another possible culprit; this one doesn't seem all that likely to me, but at least it's easy to investigate. With DBCP and non-ancient versions of the JDBC driver that use v3 protocol and real prepared statements, it is possible to (mis)configure the system to create an unbounded number of cached prepared statements on any particular connection. Older versions of DBCP were also known to have bugs which aggravated this issue when prepared statement caching was enabled, IIRC. -- Mark Lewis