Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
