Re: tuptoaster.c must *not* use SnapshotAny - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: tuptoaster.c must *not* use SnapshotAny
Date
Msg-id 200201180420.g0I4K1109918@candle.pha.pa.us
Whole thread Raw
In response to Re: tuptoaster.c must *not* use SnapshotAny  (Hiroshi Inoue <Inoue@tpf.co.jp>)
Responses Re: tuptoaster.c must *not* use SnapshotAny  (Jan Wieck <janwieck@yahoo.com>)
List pgsql-hackers
> Tom Lane wrote:
> > 
> > Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > 
> > > For example is it possible to update a toast
> > > chunk partially using SnapshotToast ?
> > 
> > As things stand (with either SnapshotToast or the old SnapshotAny way)
> > it is never possible to update an individual toast value, either
> > partially or wholly.  All you can do is lay down a new toast value (with
> > a new identifying OID) and then delete the old one.
> > 
> > But I'm not sure that this is wrong, or fixable.  Trying to update part
> > of a toasted value is very much like wanting to update part of an
> > existing row in-place, which we cannot possibly do.
> 
> Bytea seems to be considered as a candidate for BLOB
> though I think the entirely new type is preferable.
> It seems impossible to implement a functionality like
> inv_write using bytea which the current large object
> stuff has.

Agreed.  I think that was the reason we kept TOAST and large objects,
because large objects were designed for random read-write.  If we can
get large objects to auto-delete, probably with pg_depend, we can then
use them seamlessly with BLOB I/O routines.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug in pg_dump/restore -o
Next
From: Bruce Momjian
Date:
Subject: Re: Bug in pg_dump/restore -o