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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers
Date: 2014-04-07 20:29:57
Message-ID: 29011.1396902597@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2014-04-07 20:35:08 Re: B-Tree support function number 3 (strxfrm() optimization)
Previous Message Tom Lane 2014-04-07 20:25:07 Re: B-Tree support function number 3 (strxfrm() optimization)