Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers

On 2014-04-07 15:58:31 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > I've the need to persist a the result of an index_getnext() in a tuple
> > slot. I don't want to unneccessarily duplicate the tuple data itself, so
> > I'd like to use ExecStoreTuple(buffer = real_buffer) notion. But since
> > the next index_getnext()/index_endscan() will overwrite/release the
> > heaptuple I need to copy the HeapTupleData().
> > It'd be rather useful to be able to do ExecStoreTuple(tuple, slot,
> > some_buffer, true), i.e. hav ethe HeapTupleData struct freed *and* the
> > buffer pinned. There's an Assert preventing that though.
> 
> There's an assumption that if you are asking to pin a buffer, the tuple
> pointer you're passing is pointing into that buffer (and is therefore not
> something that could be pfree'd).  If it isn't pointing into a buffer,
> the tuple slot is not the place to be keeping the buffer reference.

Yea. I *have* a HeapTupleData struct pointing into the buffer. It's just
that the lifetime of the indexscans's xs_ctup isn't sufficient for my
case. So I have to allocate a new HeapTupleData struct, *again* pointing
into the buffer. I'd like to manage the lifetime of that HeapTupleData
struct (*not* the entire HeapTupleHeader blob) via the slot.
That doesn't sound too crazy to me?

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services