Bug 22593 - large object support is flawed in postgres jdbc
large object support is flawed in postgres jdbc
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: postgresql (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Need Real Name
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-12-20 14:47 EST by thoth
Modified: 2007-04-18 12:30 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-12 11:43:15 EST
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 14:50 EST, thoth
no flags Details

  None (edit)
Description thoth 2000-12-20 14:47:50 EST
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 14:50:08 EST
Created attachment 6636 [details]
Source code which triggered the exception
Comment 2 Trond Eivind Glomsrxd 2001-01-12 11:20:15 EST
The above code isn't valid... (it's org.postgresql). Besides, what is the table
definition?
Comment 3 thoth 2001-01-12 11:29:43 EST
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 11:41:40 EST
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 11:54:15 EST
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 11:58:43 EST
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.