Received: from thor.candleweb.no (thor.candleweb.no [195.139.160.194])
	by hub.org (8.9.3/8.9.3) with ESMTP id FAA01189;
	Sat, 27 May 2000 05:48:43 -0400 (EDT)
	(envelope-from gunnar@candleweb.no)
Received: (from gunnar@localhost) by thor.candleweb.no (8.10.0/8.10.0/on4)
	id <e4R9USd16587>; Sat, 27 May 2000 11:30:28 +0200 (MET DST)
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Mount <petermount@it.maidstone.gov.uk>,
	"'Gunnar R|nning'" <gunnar@candleweb.no>, pgsql-interfaces@postgresql.org,
	"PostgreSQL Developers List (E-mail)" <hackers@postgresql.org>
Subject: Re: Postgresql 7.0 JDBC exceptions - broken connections ?
References: 
 <1B3D5E532D18D311861A00600865478CF1AE65@exchange1.nt.maidstone.gov.uk>
	<1866.959353996@sss.pgh.pa.us>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Gunnar R|nning <gunnar@candleweb.no>
Date: 27 May 2000 11:30:27 +0200
In-Reply-To: Tom Lane's message of "Fri, 26 May 2000 11:13:16 -0400"
Message-ID: <x666s0uyq4.fsf@thor.candleweb.no>
Lines: 35
X-Mailer: Gnus v5.4.65/Emacs 19.34
X-Archive-Number: 200005/72

Tom Lane <tgl@sss.pgh.pa.us> writes:

> I think that this and the "Tuple received before MetaData" issue could
> have a common cause, namely running out of memory on the client side
> and not recovering well.  libpq is known to emit its equivalent of
> "Tuple received before MetaData" when the backend hasn't violated the
> protocol at all.  What happens is that libpq runs out of memory while
> trying to accumulate a large query result, "recovers" by resetting
> itself to no-query-active state, and then is surprised when the next
> message is another tuple.  (Obviously this error recovery plan needs
> work, but no one's got round to it yet.)  I wonder whether the JDBC
> driver has a similar problem, and whether these queries could have
> been retrieving enough data to trigger it?
> 

This could be a possible explanation, as some of the queries may indeed
retrieve large amounts of data. I have also noticed a couple of "Out of
Memory" exceptions that could be related(This seem to be "temporary" out of
memory exceptions, and not permanent memory leaks; so I guess these could
be caused by queries returning huge amounts of data).

> Another possibility is that the client app is failing to release
> query results when done with them, which would eventually lead to
> an out-of-memory condition even with not-so-large queries.

I don't think this is the case. I've been running the application through
OptimizeIT to profile memory and CPU usage and I haven't been able to spot
any memory leakages in the driver; The quality of the JDBC driver is
actually our main reason to migrate our application to PostgreSQL. 

regards, 

	Gunnar