Skip site navigation (1) Skip section navigation (2)

Re: Postgresql 7.0 JDBC exceptions - broken connections ?

From: Gunnar R|nning <gunnar(at)candleweb(dot)no>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>, "'Gunnar R|nning'" <gunnar(at)candleweb(dot)no>, pgsql-interfaces(at)postgresql(dot)org, "PostgreSQL Developers List (E-mail)" <hackers(at)postgresql(dot)org>
Subject: Re: Postgresql 7.0 JDBC exceptions - broken connections ?
Date: 2000-05-27 09:30:27
Message-ID: x666s0uyq4.fsf@thor.candleweb.no (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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



In response to

pgsql-hackers by date

Next:From: CBDate: 2000-05-27 10:44:11
Subject: Probably already asked but
Previous:From: selkovjrDate: 2000-05-27 07:22:32
Subject: Re: New Type

pgsql-interfaces by date

Next:From: Kevin LoDate: 2000-05-27 16:25:41
Subject: Re: [HACKERS] [DONE] PostgreSQL-7.0 binary for WinNT
Previous:From: Tomasz BrzezinaDate: 2000-05-27 08:45:41
Subject: interface to other databases

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group