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

Re: Postgresql 7.0 JDBC exceptions - broken connections ?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk>
Cc: "'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-26 15:13:16
Message-ID: 1866.959353996@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-interfaces
Peter Mount <petermount(at)it(dot)maidstone(dot)gov(dot)uk> writes:
> Unknown Response Type u

> PM: Does anyone [on Hackers] know what the u code is for? The fact it's
> in lower case tells me that the protocol/connection got broken somehow.

There is no 'u' message code.  Looks to me like the client got out of
sync with the backend and is trying to interpret data as the start of
a message.

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?

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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Ron PetersonDate: 2000-05-26 15:24:41
Subject: SPI & file locations
Previous:From: Bruce MomjianDate: 2000-05-26 14:23:14
Subject: Re: Any reason to use pg_dumpall on an idle database

pgsql-interfaces by date

Next:From: Ed LoehrDate: 2000-05-26 15:32:54
Subject: Re: Where is a mistake?
Previous:From: Alexandr ListopadDate: 2000-05-26 14:31:00
Subject: Where is a mistake?

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