From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: memory context for tuplesort return values |
Date: | 2006-02-23 22:01:41 |
Message-ID: | 26370.1140732101@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> 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.
Well, if we wanted to go that far, the simple solution is to rename
tuplesort_gettuple to something else. Guaranteed code breakage then.
However, I think this is overkill for a problem that only *might*
bite people. I kinda doubt that people are using TupleTableSlots in
add-on code, because the design of the executor makes it hard for
anything except plan nodes to obtain slots. You'd have to posit a
piece of code that isn't structured as
while ((tuple = tuplesort_gettuple(...)) != NULL)
{
process tuple;
if (should_free)
pfree(tuple);
}
but instead hangs onto the last tuple past the sort shutdown, and
yet isn't a plan node.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2006-02-23 22:13:48 | Re: memory context for tuplesort return values |
Previous Message | Alvaro Herrera | 2006-02-23 21:52:37 | Re: memory context for tuplesort return values |