pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedjdbc, pgsql6.5.1, large objects
3+ messages / 3 participants
[nested] [flat]
* jdbc, pgsql6.5.1, large objects
@ 1999-07-30 01:30 John David Garza <garza@cjas.org>
0 siblings, 2 replies; 3+ messages in thread
From: John David Garza @ 1999-07-30 01:30 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [INTERFACES] jdbc, pgsql6.5.1, large objects
@ 1999-07-30 13:57 Tom Lane <tgl@sss.pgh.pa.us>
parent: John David Garza <garza@cjas.org>
1 sibling, 0 replies; 3+ messages in thread
From: Tom Lane @ 1999-07-30 13:57 UTC (permalink / raw)
To: John David Garza <garza@cjas.org>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [INTERFACES] jdbc, pgsql6.5.1, large objects
@ 1999-07-30 14:06 Thomas Lockhart <lockhart@alumni.caltech.edu>
parent: John David Garza <garza@cjas.org>
1 sibling, 0 replies; 3+ messages in thread
From: Thomas Lockhart @ 1999-07-30 14:06 UTC (permalink / raw)
To: John David Garza <garza@cjas.org>; +Cc: pgsql-interfaces
> 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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~1999-07-30 14:06 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1999-07-30 01:30 jdbc, pgsql6.5.1, large objects John David Garza <garza@cjas.org>
1999-07-30 13:57 ` Tom Lane <tgl@sss.pgh.pa.us>
1999-07-30 14:06 ` Thomas Lockhart <lockhart@alumni.caltech.edu>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox