Red Hat Bugzilla – Bug 22593
large object support is flawed in postgres jdbc
Last modified: 2007-04-18 12:30:16 EDT
While attempting to manipulate a large object using JDBC2 for postgresql I get the following error: Exception in thread "main" FastPath protocol error: Z at postgresql.fastpath.Fastpath.fastpath(Fastpath.java:159) at postgresql.fastpath.Fastpath.fastpath(Fastpath.java:188) at postgresql.fastpath.Fastpath.getInteger(Fastpath.java:200) at postgresql.largeobject.LargeObjectManager.create(LargeObjectManager.java:162) at postgresql.jdbc2.PreparedStatement.setBytes(PreparedStatement.java:298) at com.incanta.monitor.LOBJexp.main(LOBJexp.java:20) google searches indicate that this is a bug in the /usr/lib/pgsql/jdbc6.5-1.2.jar that ships with RedHat. The workaround is to include both /usr/lib/pgsql/jdbc6.5-1.1.jar and /usr/lib/pgsql/jdbc6.5-1.2.jar in your CLASSPATH.
Created attachment 6636 [details] Source code which triggered the exception
The above code isn't valid... (it's org.postgresql). Besides, what is the table definition?
I beg to differ. amazon:2 $ rpm -q -f /usr/lib/pgsql/jdbc6.5-1.2.jar postgresql-jdbc-6.5.3-6 amazon:3 $ rpm --verify postgresql-jdbc amazon:1 $ jar tf /usr/lib/pgsql/jdbc6.5-1.2.jar | grep Driver postgresql/DriverClass.class postgresql/Driver.class amazon:4 $ jar tf /usr/lib/pgsql/jdbc6.5-1.2.jar | grep org amazon:5 $ In /usr/lib/pgsql/jdbc6.5-1.2.jar it is most certainly postgresql.Driver. The switch to org.postgresql.Driver occurred in Postgres 7 if I remember correctly. Try the test again using the environment I specified. The table's schema: CREATE TABLE lobjexp(x oid); which can be found in a comment in the fifth line of the file.
OK, sorry about that (it should have been org.postgresql or similar, though, when using the Java naming standard). Aside from that, it's working in Red Hat Linux 7 (with the Blackdown 1.1.7 jdk) with the included postgresql 7.0.2: [teg@halden teg]$ java LOBJexp 1 rows affected [teg@halden teg]$
As a note, for small entities it is often possible to upgrade the entire OS in response to a problem. For systems with a large installed base it is often a very painful process to upgrade the operating system. You have to make sure that all your components work with ALL changes to the OS (changes in command-line arguments, changes to file locations, etc). It is generally easier for the customer to QA an upgrade of a single RPM than QA an upgrade of an entire operating system.
Certainly. Also, upgrading to the RPMs of postgresql-7.0.3 from postgresql.org should fix the problem and you posted a way to work around the problem yourself.