Re: [HACKERS] Arbitrary tuple size

> > I agree this is the way to go. There is nothing I can think of that is
> > limited to how large a tuple can be. It is just accessing it from the
> > heap routines that is the problem. If the tuple is alloc'ed to be used,
> > we can paste together the parts on disk and return one tuple. If they
> > are accessing the buffer copy directly, we would have to be smart about
> > going off the end of the disk copy and moving to the next segment.
>
> Who's accessing tuple attributes directly inside the buffer
> copy (not only the header which will still be unsplitted at
> the top of the chain)?

Every call to heap_getnext(), for one. It locks the buffer, and returns
a pointer to the tuple. The next heap_getnext(), or heap_endscan()
releases the lock. The cost of returning every tuple as palloc'ed
memory would be huge. We may be able to get away with just returning
palloc'ed stuff for long tuples. That may be a simple, clean solution
that would be isolated.

In fact, if we want a copy, we call heap_copytuple() to return a
palloc'ed copy. This interface has been cleaned up so it should be
clear what is happening. The old code was messy about this.

See my comments from heap_fetch(), which does require the user to supply
a buffer variable, so they can unlock it when they are done. The old
code allowed you to pass a NULL as a buffer pointer, so there was no
locking done, and that is bad!

---------------------------------------------------------------------------

/* ----------------
* heap_fetch - retrive tuple with tid
*
* Currently ignores LP_IVALID during processing!
*
* Because this is not part of a scan, there is no way to
* automatically lock/unlock the shared buffers.
* For this reason, we require that the user retrieve the buffer
* value, and they are required to BufferRelease() it when they
* are done. If they want to make a copy of it before releasing it,
* they can call heap_copytyple().
* ----------------
*/
void
heap_fetch(Relation relation,
Snapshot snapshot,
HeapTuple tuple,
Buffer *userbuf)

--
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