From 10fcb83da6a7c5328f61ca7fb60f78c57db1bd58 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Thu, 4 Feb 2021 19:12:09 -0500 Subject: [PATCH] Fix YA incremental sort bug. switchToPresortedPrefixMode() did the wrong thing if it detected a batch boundary just at the last tuple of a fullsort group. The initially-reported symptom was a "retrieved too many tuples in a bounded sort" error, but the test case added here just silently gives the wrong answer without this patch. I (tgl) am not really happy about committing this patch without review from the incremental-sort authors, but they seem AWOL and we are hard against a release deadline. This does demonstrably make some cases better, anyway. Per bug #16846 from Yoran Heling. Back-patch to v13 where incremental sort was introduced. Neil Chen Discussion: https://postgr.es/m/16846-ae49f51ac379a4cb@postgresql.org --- src/backend/executor/nodeIncrementalSort.c | 7 +++++++ src/test/regress/expected/incremental_sort.out | 11 +++++++++++ src/test/regress/sql/incremental_sort.sql | 3 +++ 3 files changed, 21 insertions(+) diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c index b53f8a0181..360aad32c5 100644 --- a/src/backend/executor/nodeIncrementalSort.c +++ b/src/backend/executor/nodeIncrementalSort.c @@ -394,6 +394,13 @@ switchToPresortedPrefixMode(PlanState *pstate) * current prefix key group. */ ExecClearTuple(node->group_pivot); + + /* + * Also make sure we take the didn't-consume-all-the-tuples + * path below, even if this happened to be the last tuple of + * the batch. + */ + lastTuple = false; break; } } diff --git a/src/test/regress/expected/incremental_sort.out b/src/test/regress/expected/incremental_sort.out index a8cbfd9f5f..d574583844 100644 --- a/src/test/regress/expected/incremental_sort.out +++ b/src/test/regress/expected/incremental_sort.out @@ -675,6 +675,17 @@ select * from (select * from t order by a) s order by a, b limit 70; 9 | 70 (70 rows) +-- Checks case where we hit a group boundary at the last tuple of a batch. +select * from (select * from t order by a) s order by a, b limit 5; + a | b +---+--- + 1 | 1 + 2 | 2 + 3 | 3 + 4 | 4 + 9 | 5 +(5 rows) + -- Test rescan. begin; -- We force the planner to choose a plan with incremental sort on the right side diff --git a/src/test/regress/sql/incremental_sort.sql b/src/test/regress/sql/incremental_sort.sql index 62a037b0cf..9965fcd777 100644 --- a/src/test/regress/sql/incremental_sort.sql +++ b/src/test/regress/sql/incremental_sort.sql @@ -149,6 +149,9 @@ insert into t(a, b) select (case when i < 5 then i else 9 end), i from generate_ analyze t; explain (costs off) select * from (select * from t order by a) s order by a, b limit 70; select * from (select * from t order by a) s order by a, b limit 70; +-- Checks case where we hit a group boundary at the last tuple of a batch. +select * from (select * from t order by a) s order by a, b limit 5; + -- Test rescan. begin; -- We force the planner to choose a plan with incremental sort on the right side