Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 5cefbf5

Browse files
committed
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.
1 parent 6a3c6ba commit 5cefbf5

File tree

1 file changed

+16
-0
lines changed

1 file changed

+16
-0
lines changed

src/backend/utils/sort/tuplesort.c

+16
Original file line numberDiff line numberDiff line change
@@ -2172,6 +2172,22 @@ mergeruns(Tuplesortstate *state)
21722172
return;
21732173
}
21742174

2175+
if (state->sortKeys->abbrev_converter)
2176+
{
2177+
/*
2178+
* If there are multiple runs to be merged, when we go to read back
2179+
* tuples from disk, abbreviated keys will not have been stored, and we
2180+
* don't care to regenerate them. Disable abbreviation from this point
2181+
* on.
2182+
*/
2183+
state->sortKeys->abbrev_converter = NULL;
2184+
state->sortKeys->comparator = state->sortKeys->abbrev_full_comparator;
2185+
2186+
/* Not strictly necessary, but be tidy */
2187+
state->sortKeys->abbrev_abort = NULL;
2188+
state->sortKeys->abbrev_full_comparator = NULL;
2189+
}
2190+
21752191
/* End of step D2: rewind all output tapes to prepare for merging */
21762192
for (tapenum = 0; tapenum < state->tapeRange; tapenum++)
21772193
LogicalTapeRewind(state->tapeset, tapenum, false);

0 commit comments

Comments
 (0)