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

diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c
index 73e42d79451aaba42d279ace790dc27cfd42efce..82fa800cb1711aaca19201bebddf6e683bb90ef5 100644 (file)
--- 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 a8cbfd9f5f995176025bdb4210922878fc5b3941..d5745838440bff8693ea2a9f16b619a38d4457eb 100644 (file)
--- 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 62a037b0cfb6732b8209c485403cb1149ec7e4b2..9965fcd77765b16dc7f9ada0b5e44af82b5962bc 100644 (file)
--- 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