Bug 22593 - large object support is flawed in postgres jdbc
Summary: large object support is flawed in postgres jdbc
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: Need Real Name
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-12-20 19:47 UTC by thoth
Modified: 2007-04-18 16:30 UTC (History)
0 users

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: ---


Attachments (Terms of Use)
Source code which triggered the exception (1023 bytes, text/plain)
2000-12-20 19:50 UTC, thoth
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.