Bug 22593

Summary: large object support is flawed in postgres jdbc
Product: [Retired] Red Hat Linux Reporter: thoth
Component: postgresqlAssignee: Trond Eivind Glomsrxd <teg>
Status: CLOSED CURRENTRELEASE QA Contact: Need Real Name <pelzak>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-01-12 16:43:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Source code which triggered the exception none

Description thoth 2000-12-20 19:47:50 UTC
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.

Comment 1 thoth 2000-12-20 19:50:08 UTC
Created attachment 6636 [details]
Source code which triggered the exception

Comment 2 Trond Eivind Glomsrxd 2001-01-12 16:20:15 UTC
The above code isn't valid... (it's org.postgresql). Besides, what is the table
definition?

Comment 3 thoth 2001-01-12 16:29:43 UTC
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.


Comment 4 Trond Eivind Glomsrxd 2001-01-12 16:41:40 UTC
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]$

Comment 5 thoth 2001-01-12 16:54:15 UTC
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.


Comment 6 Trond Eivind Glomsrxd 2001-01-12 16:58:43 UTC
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.