RE: Postgresql 7.0 JDBC exceptions - broken connecti ons ?
От | Peter Mount |
---|---|
Тема | RE: Postgresql 7.0 JDBC exceptions - broken connecti ons ? |
Дата | |
Msg-id | 1B3D5E532D18D311861A00600865478CF1AE70@EXCHANGE1 обсуждение исходный текст |
Список | pgsql-interfaces |
Sorry for the delay - 3 day weekend here in the UK ;-) As usual when replying from here, replies prefixed with PM: -- Peter Mount Enterprise Support Maidstone Borough Council Any views stated are my own, and not those of Maidstone Borough Council. -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Friday, May 26, 2000 4:13 PM To: Peter Mount Cc: 'Gunnar R|nning'; pgsql-interfaces@postgresql.org; PostgreSQL Developers List (E-mail) Subject: Re: [INTERFACES] Postgresql 7.0 JDBC exceptions - broken connections ? Peter Mount <petermount@it.maidstone.gov.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? PM: The protocol side of the JDBC driver was based on libpq, so it is possible that this sort of problem could manifest itself in JDBC. 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. PM: Garbage collection can be strange (and different on each platform). Unfortunately you can't guarantee that garbage collection will occur regularly (or when the VM's memory fills - normally 16Mb), or that it will run at all. regards, tom lane
В списке pgsql-interfaces по дате отправления: