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

Re: [BUGS] no way in LargeObject API to detect short read?

From: Peter Mount <peter(at)retep(dot)org(dot)uk>
To: Barry Lind <barry(at)xythos(dot)com>
Cc: PostgreSQL jdbc list <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: [BUGS] no way in LargeObject API to detect short read?
Date: 2001-01-27 17:01:24
Message-ID: 5.0.2.1.0.20010127165622.009e6110@mail.retep.org.uk (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-jdbc
At 15:37 26/01/01 -0800, Barry Lind wrote:
>Peter,
>
>Given the current implementation of size(), I don't think this is a good
>solution to the problem at hand.  Since size() is an expensive call
>(especially on large files), using it in this way wouldn't be a
>performant solution.  Using size() also requires additional round trips
>to the database to get this information.  There needs to be a better
>solution that doesn't require the additional overhead.


That's exactly what I was thinking of. Most of the largeobject API is based 
on libpq hence where this came from. I don't think there is 
anything  available elsewhere for getting the size.

Yes, there needs to be a better way.

Peter


>thanks,
>--Barry
>
>Peter T Mount wrote:
> >
> > Hmmm, what's the performance issues with this? Is there going to be a 
> problem
> > with very large LargeObject's?
> >
> > Quoting "Paul M. Aoki" <aoki(at)acm(dot)org>:
> >
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > > > Anyone able to fix this?
> > >
> > > here's a hack we've been using in-house (written by Jun Gabayan,
> > > <jgabayan(at)pahv(dot)xerox(dot)com>).
> > >
> > > you may not like the style but it's a stab at a solution.
> > > --
> > >  Paul M. Aoki / Xerox Palo Alto Research Center / 3333 Coyote Hill Road
> > >  aoki(at)acm(dot)org / Computer Science Laboratory     / Palo Alto, CA
> > > 94304-1314
> > >
> > > Index: LargeObject.java
> > > ===================================================================
> > > RCS file:
> > > 
> /project/placeless/cvsroot/placeless2/src/org/postgresql/largeobject/LargeObje
> > ct.java,v
> > > retrieving revision 1.1
> > > retrieving revision 1.3
> > > diff -r1.1 -r1.3
> > > 64c64,67
> > > <
> > > ---
> > > >
> > > >   private int pos = 0; //current position
> > > >   private int size = 0;
> > > >
> > > 85a89,90
> > > >     pos = tell();
> > > >     size = size();
> > > 102a108
> > > >     if(fd == 0) return;
> > > 105a112
> > > >     fd = 0;
> > > 118a126,132
> > > >         // calculate available data to read to avoid reading pass the
> > > end
> > > >         // to avoid an exception
> > > >         pos = tell();
> > > >         int avail = size - pos;
> > > >         if(avail == 0) return null;
> > > >         if(avail < len) len = avail;
> > > >         try {
> > > 123c137,141
> > > <
> > > ---
> > > >         }catch(SQLException se) {
> > > >           System.out.println("***LargeObject.read: Caught
> > > SQLException: " + se.getMessage());
> > > >           return null;
> > > >         }
> > > >
> > > 157c175
> > > <   public void read(byte buf[],int off,int len) throws SQLException
> > > ---
> > > >   public int read(byte buf[],int off,int len) throws SQLException
> > > 159c177,180
> > > <     System.arraycopy(read(len),0,buf,off,len);
> > > ---
> > > >     byte mybuf[] = read(len);
> > > >     int sz = (mybuf != null) ? mybuf.length : -1; //must return -1 for
> > > end of data
> > > >     if(sz > 0) System.arraycopy(mybuf,0,buf,off,sz);
> > > >     return sz;
> > >
> >
> > --
> > Peter Mount peter(at)retep(dot)org(dot)uk
> > PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/
> > RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/


In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2001-01-27 19:16:50
Subject: Re: memory leak in date_part() function in v7.1beta3 ?
Previous:From: dojDate: 2001-01-27 14:02:05
Subject: memory leak in date_part() function in v7.1beta3 ?

pgsql-jdbc by date

Next:From: Philip WarnerDate: 2001-01-28 01:53:01
Subject: Re: Open 7.1 items
Previous:From: Dmitry ChernikovDate: 2001-01-27 14:58:29
Subject:

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