@@ -3083,14 +3083,14 @@ dumpbatch(Tuplesortstate *state, bool alltuples)
30833083 * a call with no subsequent run actually written to destTape), we prefer
30843084 * to write out a 0 tuple run.
30853085 *
3086- *mergepreread()/mergeprereadone() are prepared for 0 tuple runs, and
3087- *will reliably mark the tape inactive for the merge when called from
3088- *beginmerge(). This case is therefore similar to the case where
3089- *mergeonerun() finds a dummy run for the tape, and so doesn't need to
3090- *merge a run from the tape (or conceptually "merges" the dummy run, if
3091- *you prefer). According to Knuth, Algorithm D "isn't strictly optimal"
3092- *in its method of distribution and dummy run assignment; this edge case
3093- *seems very unlikely to make that appreciably worse.
3086+ *mergereadnext() is prepared for 0 tuple runs, and will reliably mark
3087+ * the tape inactive for the merge when called from beginmerge(). This
3088+ * case is therefore similar to the case where mergeonerun() finds a dummy
3089+ * run for the tape, and so doesn't need to merge a run from the tape (or
3090+ * conceptually "merges" the dummy run, if you prefer). According to
3091+ * Knuth, Algorithm D "isn't strictly optimal" in its method of
3092+ * distribution and dummy run assignment; this edge case seems very
3093+ * unlikely to make that appreciably worse.
30943094 */
30953095Assert (state -> status == TSS_BUILDRUNS );
30963096