Re: memory context for tuplesort return values

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: memory context for tuplesort return values
Date: 2006-02-23 21:21:59
Message-ID: 20060223212158.GA8798@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-02-23 21:27:51 Re: memory context for tuplesort return values
Previous Message Tom Lane 2006-02-23 21:17:15 Re: Foreign keys for non-default datatypes