From: | Daniel Migowski <dmigowski(at)ikoffice(dot)de> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com>, PostgreSQL - JDBC <pgsql-jdbc(at)postgresql(dot)org> |
Subject: | Re: Deadlock detection |
Date: | 2009-01-21 12:17:10 |
Message-ID: | 49771246.9020306@ikoffice.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Simon Riggs schrieb:
> As we know from recent versions, the JDBC driver can deadlock. We also
> know that the deadlock detector as exists does not detect all types of
> deadlock and isn't foolproof at that either. Not criticism, just
> summarising.
>
I don't know if this of help for you, but one case of deadlocking can
occur because of filled stream buffers on both ends of the connections.
I had a similar situation where I issued a large script with 100.000
INSERT statements to the database by JDBC. Those Statements all returned
their answer bytes after each invokation on the server, then those bytes
filled the client receive buffer, after that the server send buffer got
filled, and then the server process got blocked. Now the receive buffer
of the server fills, and then the client send buffer.
I "solved" the problem for scripts of our size by drastically increasing
the input buffer size on the client side. I modified PGStream.java to
include the following line in "changeConnection()":
connection.setReceiveBufferSize(256*1024);
I don't know if there is a more elegant way to handle this, but for us
it works. Maybe for you, too. As far as i know (which is not much about
the driver internals) this is the only way to make the driver hang.
With best regards,
Daniel Migowski
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2009-01-21 13:35:17 | Re: Deadlock detection |
Previous Message | Oliver Jowett | 2009-01-21 11:38:50 | Re: Deadlock detection |