Thread: Driver Bug
Hi,
I've found a bug in the drivers which seem to occur in the "8.1-408 JDBC 3" and "8.2-504 JDBC 3" drivers when executing on a 8.1 and 8.2 PG Server. The problem does not occur on a 8.0 server.
The problem occurs when the following situation is produced ...
1. Connection.autoCommit(true);
2. Statement.setMaxRows(1);
3. Statement.execute("select * from information_schema.parameters");
In this case, the Statement.execute() will never return and basically put the application in a hanging state. If the Connection.autoCommit() is set to false then all works well. If the Statement.setMaxRows() is set to a number higher then the number of rows to be returned then all works well. But if you auto commit is true and max rows is less then the total number of rows and the statement is executed on PG 8.1 or 8.2.
Any ideas?
thanks
-John
I've found a bug in the drivers which seem to occur in the "8.1-408 JDBC 3" and "8.2-504 JDBC 3" drivers when executing on a 8.1 and 8.2 PG Server. The problem does not occur on a 8.0 server.
The problem occurs when the following situation is produced ...
1. Connection.autoCommit(true);
2. Statement.setMaxRows(1);
3. Statement.execute("select * from information_schema.parameters");
In this case, the Statement.execute() will never return and basically put the application in a hanging state. If the Connection.autoCommit() is set to false then all works well. If the Statement.setMaxRows() is set to a number higher then the number of rows to be returned then all works well. But if you auto commit is true and max rows is less then the total number of rows and the statement is executed on PG 8.1 or 8.2.
Any ideas?
thanks
-John
On Wed, 20 Dec 2006, John LH wrote:
> I've found a bug in the drivers which seem to occur in the "8.1-408 JDBC 3"
> and "8.2-504 JDBC 3" drivers when executing on a 8.1 and 8.2 PG Server. The
> problem does not occur on a 8.0 server.
>
> The problem occurs when the following situation is produced ...
>
> 1. Connection.autoCommit(true);
> 2. Statement.setMaxRows(1);
> 3. Statement.execute("select * from information_schema.parameters");
>
> In this case, the Statement.execute() will never return and basically put
> the application in a hanging state.
I cannot reproduce this on a 8.1.5 database with the 8.2-504 driver using
the attached code. Can you? If so could you send back the results of
it's execution until the point it hangs with the additional connection URL
parameter loglevel=2?
Is it possible you just have a very large amount of data in
information_schema.parameters and it's taking a while to respond?
Kris Jurka
On Thu, 4 Jan 2007, Kris Jurka wrote: > I cannot reproduce this on a 8.1.5 database with the 8.2-504 driver using the > attached code. Code actually attached this time. Kris Jurka
Attachment
John LH wrote: > > Thanks for the reply. I did some more detailed testing and found the > following results ... > > 8.1.1 : On this it hangs > 8.1.4 : On this version it throws this exception ... > > I am now thinking that this is a bug in the early builds of 8.1.x. This > is sufficient for us, we will just upgrade and if anyone else has an > issue with this specifically we will tell them to upgrade. > Checking the release notes: http://www.postgresql.org/docs/current/static/release-8-1-5.html I believe it is covered by this entry: Fix mishandling of AFTER triggers when query contains a SQL function returning multiple rows (Tom) The difference between a hang and a crash seems to be whether the backend was compiled with --enable-cassert.