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

Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-07 16:29:57 -0400, Tom Lane wrote:
>> In that case you should have another tuple slot of your own and let it
>> keep the tuple (and buffer pin).

> that's not going to work, because scantuple might be free'd or pointing
> to another tuple, from the next index_getnext() call. Right?

It's true that scantuple is probably pointing at the xs_ctup field of the
IndexScanDesc, so you need to put that data somewhere else if you want
to hold onto it past the current loop iteration.

> So what I now do is essentially:
> while ((scantuple = index_getnext(scan, ForwardScanDirection)) != NULL)
> {
> ...
>         ht = palloc(sizeof(HeapTupleData)); /* in the right context */
>         memcpy(ht, scantuple, sizeof(HeapTupleData));
>         ExecStoreTuple(ht, slot, scan->xs_cbuf, false);
>         slot->tts_shouldFree = true;
> ...
> }

Well, that is certainly messy.  I think you could just use a local
HeapTupleData variable instead of palloc'ing every time, where "local"
means "has lifespan similar to the slot pointer".  That is
     HeapTupleData my_htup;
     while ((scantuple = index_getnext(scan, ForwardScanDirection)) != NULL)     {    memcpy(&my_htup, scantuple,
sizeof(HeapTupleData));   ExecStoreTuple(&my_htup, slot, scan->xs_cbuf, false);     }
 

If my_htup is just a local, you'd want to clear the slot before my_htup
goes out of scope, just to be sure it doesn't try to dereference a
dangling pointer.  There's some vaguely similar hacking near the end of
ExecDelete.
        regards, tom lane