diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-04 19:12:09 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-04 19:12:14 -0500 |
| commit | 82e0e29308dedbc6000e73329beb112ae7e1ad39 (patch) | |
| tree | 8581de677c324f051ce021eac95e56bc20eb7bf4 /src/backend/executor/nodeIncrementalSort.c | |
| parent | c34787f910585f82320f78b0afd53a6a170aa229 (diff) | |
| download | postgresql-82e0e29308dedbc6000e73329beb112ae7e1ad39.tar.gz postgresql-82e0e29308dedbc6000e73329beb112ae7e1ad39.zip | |
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
Diffstat (limited to 'src/backend/executor/nodeIncrementalSort.c')
| -rw-r--r-- | src/backend/executor/nodeIncrementalSort.c | 7 |
1 files changed, 7 insertions, 0 deletions
diff --git a/src/backend/executor/nodeIncrementalSort.c b/src/backend/executor/nodeIncrementalSort.c index 73e42d79451..82fa800cb17 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; } } |