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

From Tom Lane
Subject Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers
Date
Msg-id 29011.1396902597@sss.pgh.pa.us
Whole thread Raw
In response to Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@2ndquadrant.com> writes:
> On 2014-04-07 15:58:31 -0400, Tom Lane wrote:
>> 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?

In that case you should have another tuple slot of your own and let it
keep the tuple (and buffer pin).
        regards, tom lane



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: CREATE FOREIGN TABLE ( ... LIKE ... )
Next
From: Peter Geoghegan
Date:
Subject: Re: B-Tree support function number 3 (strxfrm() optimization)