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
- 0001-Avoid-copying-within-tuplesort_gettupleslot.patch (text/x-patch) patch 0001
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
-
Fix duplicated words in comment.
- b58c433ef90b 10.0 landed
-
Remove should_free arguments to tuplesort routines.
- 3856cf9607f4 10.0 landed
-
Fix use-after-free around DISTINCT transition function calls.
- d8589946ddd5 10.0 cited