Re: memory context for tuplesort return values

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: memory context for tuplesort return values
Дата
Msg-id 20060223212158.GA8798@surnet.cl
обсуждение исходный текст
Ответ на memory context for tuplesort return values  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: memory context for tuplesort return values  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> I've been modifying tuplesort.c to keep all the sort's local data in a
> separate memory context, to simplify and speed up cleaning up the data
> during tuplesort_end.  I thought this would be a straightforward change,
> but was disillusioned when I got a core dump while testing :-(.  On
> investigation the problem is that nodeSort.c keeps the tuple pointer
> returned by tuplesort.c in a TupleTableSlot, and the order of operations
> during plan shutdown is such that the slot tries to pfree the tuple
> only after tuplesort_end has been called.  Of course this means it's
> pfree'ing already-released memory.

Is it possible to make the TupleTableSlot not free the tuple
automatically?  AFAIR there is a parameter to the creation routine of a
TupleTableSlot to make it so, but I don't know if it's possible to use
in tuplesort.c's case at all.  (Or even if we are talking at the same
level here -- my reading of that code was very shallow.)

> 1. Document an ordering constraint that the result of tuplesort_gettuple
> must be pfree'd, if at all, before tuplesort_end.  AFAICT this would
> require only one simple change in the existing backend code (add an
> ExecClearTuple at a suitable spot in nodeSort.c).  However there is the
> potential to break add-on modules, if anyone is using tuplesort directly.

Maybe it is possible to write some sort of magic number to the
TupleTableSlot before it is destroyed, which could be checked if
somebody tries to destroy it again, to warn them that the code should be
changed to cope with the new order of things.  This could be compiled
conditionally on MEMORY_CONTEXT_CHECKING or something else that is only
defined in --enable-cassert builds, so extension developers are likely
to trip on it.  It wouldn't be bullet-proof, because of course the
memory could be used for something else before the subsequent invalid
destruction, but it could help.

(Actually the first idea that came to mind was checking for the 0x7f
pattern ...)

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Foreign keys for non-default datatypes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: memory context for tuplesort return values