Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers
От | Tom Lane |
---|---|
Тема | Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers |
Дата | |
Msg-id | 27448.1396900711@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Why is it not sane to pass
ExecStoreTuple(shouldFree=true) for tuples point into buffers
|
Список | pgsql-hackers |
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. I'm disinclined to remove that Assert because failing to pin a buffer when you *are* passing a pointer into it is a very bad, hard-to-find bug. Admittedly the Assert is only a partial defense against that problem, but it's better than nothing. regards, tom lane
В списке pgsql-hackers по дате отправления: