Обсуждение: jdbc, pgsql6.5.1, large objects

Hey folks,

Let's see, my admin just upgraded postgresql to 6.5.1 and now it looks
like FastPath isn't working. More specifically, after creating and opening
a large object using the LargeObjectManager class, any other access
attempts throws the following:

FastPath call returned ERROR:  lo_write: invalid large obj descriptor (0)
FastPath call returned ERROR:  lo_write: invalid large obj descriptor (0)       at
postgresql.fastpath.Fastpath.fastpath(Fastpath.java:141)      at
postgresql.fastpath.Fastpath.fastpath(Fastpath.java:188)      at
postgresql.largeobject.LargeObject.write(LargeObject.java:173)      at
postgresql.largeobject.LargeObject.write(LargeObject.java:188)      at uploadImage.main(uploadImage.java:87)
 

In this case, line 87 in uploadImage is:
...
85      LargeObject pict = lobjm.open(num);
86      while ((s=fblob.read(buf, 0, 256)) > 0) {
87              pict.write(buf, 0, s);}
...

Before upgrading to 6.5.1, this program worked fine. Calls to tell, size,
read all cause the same type of exceptions.

Any help would be appreciated.

Other info: FreeBSD 3.2, jdk1.1.8

Thanks,
John David Garza
garza@keyframe.cjas.org

John David Garza <garza@cjas.org> writes:
> FastPath call returned ERROR:  lo_write: invalid large obj descriptor (0)

This is achieving FAQ status very rapidly.  6.5 enforces the rule that
large object descriptors can only be used within a single transaction.
(This rule has always been in the documentation, but prior releases
didn't check, and most of the time referring to an LO opened in an
old transaction would still work...)

So you need an explicit begin/end transaction around your lo_open ...
lo_close sequence.  In JDBC I think you gotta turn off autocommit,
but I'm not familiar enough with JDBC to quote exact commands for you.
        regards, tom lane

> Let's see, my admin just upgraded postgresql to 6.5.1 and now it looks
> like FastPath isn't working. More specifically, after creating and opening
> a large object using the LargeObjectManager class, any other access
> attempts throws the following:
> Before upgrading to 6.5.1, this program worked fine. Calls to tell, size,
> read all cause the same type of exceptions.

Put all the accesses to a large object inside a transaction. The
restriction was always there in principle, but was not enforced in
earlier releases.
                    - Thomas

-- 
Thomas Lockhart                lockhart@alumni.caltech.edu
South Pasadena, California