diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index 20cfb0b139..5ff81ed95a 100644
--- a/src/backend/utils/sort/tuplesort.c
+++ b/src/backend/utils/sort/tuplesort.c
@@ -3083,14 +3083,14 @@ dumpbatch(Tuplesortstate *state, bool alltuples)
 	 * a call with no subsequent run actually written to destTape), we prefer
 	 * to write out a 0 tuple run.
 	 *
-	 * mergepreread()/mergeprereadone() are prepared for 0 tuple runs, and
-	 * will reliably mark the tape inactive for the merge when called from
-	 * beginmerge().  This case is therefore similar to the case where
-	 * mergeonerun() finds a dummy run for the tape, and so doesn't need to
-	 * merge a run from the tape (or conceptually "merges" the dummy run, if
-	 * you prefer).  According to Knuth, Algorithm D "isn't strictly optimal"
-	 * in its method of distribution and dummy run assignment; this edge case
-	 * seems very unlikely to make that appreciably worse.
+	 * mergereadnext() is prepared for 0 tuple runs, and will reliably mark
+	 * the tape inactive for the merge when called from beginmerge().  This
+	 * case is therefore similar to the case where mergeonerun() finds a dummy
+	 * run for the tape, and so doesn't need to merge a run from the tape (or
+	 * conceptually "merges" the dummy run, if you prefer).  According to
+	 * Knuth, Algorithm D "isn't strictly optimal" in its method of
+	 * distribution and dummy run assignment; this edge case seems very
+	 * unlikely to make that appreciably worse.
 	 */
 	Assert(state->status == TSS_BUILDRUNS);