I have a DB where each row is *giagantic* (up to 60mb in size). I have
my fetch size set to 200. I realize that this isnt so smart, but the
problem it causes is more generic than my specific situation.
While reading, an OutOfMemoryError gets thrown and I start closing
things down. So far, so good.
I close the statement and close the result set - freeing up a bunch of
memory. Unfortunately, I get problems when I try to close the
connection and release it to the connection pool. This fails - most
likely because it was in the middle of reading a tuple when it was
rudely interupted by running out of memory.
It actually runs out of memory in PGStream.ReceiveTupleV3(), called from
QueryExecutorImpl.processResults().
Later, the connection is closed and the
PooledConnectionImpl$ConnectionHandler.invoke() is called, which
(because we're not AutoCommit) attempt to rollback the transaction with
a con.rollback(). This is where the problem occurs.
Inside QueryExecutorImpl.processResults(), it gets a "\" from the server
(highly likely from the bytea returned from the original query). It, of
course, doesnt understand this and throws an "An I/O error occured while
sending to the backend." error.
The end result is that the connection doesnt appear to be closed and
released back to the connection pool. This means that connections to
the database are being leaked, and probably a fair amount of memory.
This, of course, causes the OutOfMemory error to happen more often.
dave