Fix possible sorting error when aborting use of abbreviated keys.

Due to an error in the abbreviated key abort logic, the most recently
processed SortTuple could be incorrectly marked NULL, resulting in an
incorrect final sort order.

In the worst case, this could result in a corrupt btree index, which
would need to be rebuild using REINDEX.  However, abbrevation doesn't
abort very often, not all data types use it, and only one tuple would
end up in the wrong place, so the practical impact of this mistake may
be somewhat limited.

Report and patch by Peter Geoghegan.

diff --git a/src/backend/utils/sort/tuplesort.c b/src/backend/utils/sort/tuplesort.c
index cf1cdcbeab58ee2c14783c5c7158cdb988802de3..647083210e8dd86ff9c5b072834a4e802b1c0f8d 100644 (file)
--- a/src/backend/utils/sort/tuplesort.c
+++ b/src/backend/utils/sort/tuplesort.c
@@ -1314,7 +1314,7 @@ tuplesort_putindextuplevalues(Tuplesortstate *state, Relation rel,
            mtup->datum1 = index_getattr(tuple,
                                         1,
                                         RelationGetDescr(state->indexRel),
-                                        &stup.isnull1);
+                                        &mtup->isnull1);
        }
    }
 
@@ -3440,7 +3440,7 @@ copytup_cluster(Tuplesortstate *state, SortTuple *stup, void *tup)
            mtup->datum1 = heap_getattr(tuple,
                                      state->indexInfo->ii_KeyAttrNumbers[0],
                                        state->tupDesc,
-                                       &stup->isnull1);
+                                       &mtup->isnull1);
        }
    }
 }
@@ -3744,7 +3744,7 @@ copytup_index(Tuplesortstate *state, SortTuple *stup, void *tup)
            mtup->datum1 = index_getattr(tuple,
                                         1,
                                         RelationGetDescr(state->indexRel),
-                                        &stup->isnull1);
+                                        &mtup->isnull1);
        }
    }
 }