postgres.git / summary / log / commit / refs

commit    5cefbf5a6c4466ac6b1cc2a4316b4eba9108c802
Author:   Robert Haas <rhaas@postgresql.org>
Date:     Fri Jan 23 16:58:31 2015 +0000

    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 6d3aa889bc5..b6e302fc9ca 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);


[parent: 6a3c6ba0ba2b]