From 5cefbf5a6c4466ac6b1cc2a4316b4eba9108c802 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Fri, 23 Jan 2015 11:58:31 -0500 Subject: [PATCH] Don't use abbreviated keys for the final merge pass. When we write tuples out to disk and read them back in, the abbreviated keys become non-abbreviated, because the readtup routines don't know anything about abbreviation. But without this fix, the rest of the code still thinks the abbreviation-aware compartor should be used, so chaos ensues. Report by Andrew Gierth; patch by Peter Geoghegan. --- src/backend/utils/sort/tuplesort.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c index 6d3aa889bc..b6e302fc9c 100644 --- a/src/backend/utils/sort/tuplesort.c +++ b/src/backend/utils/sort/tuplesort.c @@ -2172,6 +2172,22 @@ mergeruns(Tuplesortstate *state) return; } + if (state->sortKeys->abbrev_converter) + { + /* + * If there are multiple runs to be merged, when we go to read back + * tuples from disk, abbreviated keys will not have been stored, and we + * don't care to regenerate them. Disable abbreviation from this point + * on. + */ + state->sortKeys->abbrev_converter = NULL; + state->sortKeys->comparator = state->sortKeys->abbrev_full_comparator; + + /* Not strictly necessary, but be tidy */ + state->sortKeys->abbrev_abort = NULL; + state->sortKeys->abbrev_full_comparator = NULL; + } + /* End of step D2: rewind all output tapes to prepare for merging */ for (tapenum = 0; tapenum < state->tapeRange; tapenum++) LogicalTapeRewind(state->tapeset, tapenum, false); -- 2.40.0