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  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: "Transaction local" statistics are incorrect at speed
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Why is it not sane to pass ExecStoreTuple(shouldFree=true) for tuples point into buffers