Re: tuplesort_gettuple_common() and *should_free argument

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Peter Geoghegan <pg@heroku.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, hlinnaka <hlinnaka@iki.fi>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-03-14T01:14:07Z
Lists: pgsql-hackers

Attachments

On Wed, Jan 25, 2017 at 3:11 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Jan 25, 2017 at 3:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Please.  You might want to hit the existing ones with a separate patch,
>> but it doesn't much matter; I'd be just as happy with a patch that did
>> both things.
>
> Got it.

Attached is a patch that does both things at once. The internal
function tuplesort_gettuple_common() still mentions repeated fetches,
since that context matters to its internal callers. The various
external-facing functions have a simpler, stricter contract, as
discussed.

I didn't end up adding a line like "copy=FALSE is recommended only
when the next tuplesort manipulation will be another
tuplesort_gettupleslot fetch into the same slot", which you suggested.
When the tuplesort state machine is in any state following
"performing" a sort, there are very few remaining sane manipulations.
Just things like skipping or seeking around for tuples, and actually
ending the tuplesort and releasing resources.

-- 
Peter Geoghegan

Commits

  1. Fix duplicated words in comment.

  2. Remove should_free arguments to tuplesort routines.

  3. Fix use-after-free around DISTINCT transition function calls.