Re: memory context for tuplesort return values

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.