Skip site navigation (1) Skip section navigation (2)

Re: Blob getBinaryStream issue.

From: Kris Jurka <books(at)ejurka(dot)com>
To: Pete Lewin-Harris <pete(at)illumining(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Blob getBinaryStream issue.
Date: 2004-06-24 07:01:52
Message-ID: Pine.BSO.4.56.0406240150530.27120@leary.csoft.net (view raw or flat)
Thread:
Lists: pgsql-jdbc

On Wed, 23 Jun 2004, Pete Lewin-Harris wrote:

> I'm getting an odd result when I try and get the length of a blob after I
> have closed it's binary stream. In the snippet below, the final line throws
> a PSQL Exception with the message 'FastPath call returned ERROR: invalid
> large-object descriptor: 0'. If the final line is removed and
> getBinaryStream called again, the second stream fails on first read with a
> null pointer exception.
> 
> Firstly, is it a bug that multiple calls to getBinaryStream do not return
> separate InputStream objects or is it just the way it works and I need to
> re-get the blob if I want to read the stream again?

This looks like a bug to me.  They do actually return separate InputStream
objects, but the close method for it closes the underlying shared Blob.  
Of course since they are based on the same shared blob, it would be
difficult to use more than one stream at a time since the actual position
information is stored in the shared object.  I'll investigate further, but 
for now a potential simple fix would be to change 
org.postgresql.largeobject.BlobInputStream#close() to not close the 
underlying large object.

Kris Jurka


In response to

pgsql-jdbc by date

Next:From: Markus SchaberDate: 2004-06-24 08:08:53
Subject: COPY Support Patch - actualized version?
Previous:From: Kris JurkaDate: 2004-06-24 06:35:18
Subject: Re: PoolingDataSource executeUpdate

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group