Re: [INTERFACES] Postgresql 7.0 JDBC exceptions - broken connections ?
От | Gunnar R|nning |
---|---|
Тема | Re: [INTERFACES] Postgresql 7.0 JDBC exceptions - broken connections ? |
Дата | |
Msg-id | x666s0uyq4.fsf@thor.candleweb.no обсуждение исходный текст |
Ответ на | RE: [INTERFACES] Postgresql 7.0 JDBC exceptions - broken connecti ons ? (Peter Mount <petermount@it.maidstone.gov.uk>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: