Re: memory context for tuplesort return values

Tom Lane wrote:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > 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.
> 
> > 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.
> 
> The problem is that we specifically *want* the caller to free the tuple
> when done with it.  The API is essentially that tuplesort_gettuple is
> passing ownership of the tuple over to the caller.  Without this it
> seems very hard to avoid an essentially useless palloc/pfree cycle
> per tuple.

Oh, true, I had got it backwards.  So we would be turning a valid
operation into a memory leak for extension developers :-(  Since you
assert that solution #2 is pretty messy, it would be good to stay away
from it.  However, if following #1 I'm not sure that documenting the new
behavior is enough.  I don't have any better suggestion however :-(

Crazy ideas: add a #warning or #error to the header file unless there is
some special symbol previously defined, something like
#define I_UNDERSTAND_MEM_ALLOC_IN_TUPLETABLESLOT
which means the developer did update his code.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.