Re: [HACKERS] Backend problem with large objects

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: t-ishii(at)sra(dot)co(dot)jp
Cc: I(dot)A(dot)N(dot)Grant(at)damtp(dot)cam(dot)ac(dot)uk, t-ishii(at)sra(dot)co(dot)jp, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Backend problem with large objects
Date: 1999-02-04 14:52:42
Message-ID: 199902041452.JAA13924@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Applied manually. The patch did not apply cleanly, and needed a &tuple
in inv_wrold, not tuple.

> > On Tue, 2 Feb 1999, Tatsuo Ishii wrote:
> >
> > > Reproduced here too. Seems very old and known problem of large object
> > > (writing into in the middle of a large object does not work).
> >
> > Many thanks, does this mean it's not likely to be fixed? If so I'll take
> > this to the documentation list, if there is one. But first, can anyone
> > explain what *is* allowed in lo_write after lo_lseek? Is it OK to
> > overwrite a large object for example?
>
> Ok. I think I have found the source of the problem. Please apply
> included patches and try again.
>
> > I also note that there is no way to truncate a large object without
> > reading the beginning bit and copying it out to another new large object,
> > which involves it going down the wire to the client and then back again.
> > Are there any plans to implement lo_trunc or something? Perhaps this is
> > difficult for the same reason lo_write is difficult inside a large object.
>
> Seems not too difficult, but I don't have time to do that.
> ---
> Tatsuo Ishii
>
> ----------------------------- cut here ----------------------------------
> *** postgresql-6.4.2/src/backend/storage/large_object/inv_api.c.orig Sun Dec 13 14:08:19 1998
> --- postgresql-6.4.2/src/backend/storage/large_object/inv_api.c Thu Feb 4 22:02:43 1999
> ***************
> *** 545,555 ****
> tuplen = inv_wrnew(obj_desc, buf, nbytes - nwritten);
> else
> {
> ! if (obj_desc->offset > obj_desc->highbyte)
> tuplen = inv_wrnew(obj_desc, buf, nbytes - nwritten);
> else
> tuplen = inv_wrold(obj_desc, buf, nbytes - nwritten, tuple, buffer);
> ! ReleaseBuffer(buffer);
> }
>
> /* move pointers past the amount we just wrote */
> --- 545,561 ----
> tuplen = inv_wrnew(obj_desc, buf, nbytes - nwritten);
> else
> {
> ! if (obj_desc->offset > obj_desc->highbyte) {
> tuplen = inv_wrnew(obj_desc, buf, nbytes - nwritten);
> + ReleaseBuffer(buffer);
> + }
> else
> tuplen = inv_wrold(obj_desc, buf, nbytes - nwritten, tuple, buffer);
> ! /* inv_wrold() has already issued WriteBuffer()
> ! which has decremented local reference counter
> ! (LocalRefCount). So we should not call
> ! ReleaseBuffer() here. -- Tatsuo 99/2/4
> ! ReleaseBuffer(buffer); */
> }
>
> /* move pointers past the amount we just wrote */
>
>

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 1999-02-04 17:15:06 Re: [HACKERS] small bug fix for ecpg
Previous Message Tatsuo Ishii 1999-02-04 14:14:01 Re: [HACKERS] Backend problem with large objects