mirror of
https://git.postgresql.org/git/postgresql.git
synced 2025-03-07 19:47:50 +08:00
Adjust tuplesort.c based on the fact that we never use the OS's qsort().
Our own qsort_arg() implementation doesn't have the defect previously observed to affect only QNX 4, so it seems sufficiently to assert that it isn't broken rather than retesting. Also, update a few comments to clarify why it's valuable to retain a tie-break rule based on CTID during index builds. Peter Geoghegan, with slight tweaks by me.
This commit is contained in:
parent
2d1371d3ee
commit
c5a03256c7
@ -3047,17 +3047,19 @@ comparetup_index_btree(const SortTuple *a, const SortTuple *b,
|
|||||||
* sort algorithm wouldn't have checked whether one must appear before the
|
* sort algorithm wouldn't have checked whether one must appear before the
|
||||||
* other.
|
* other.
|
||||||
*
|
*
|
||||||
* Some rather brain-dead implementations of qsort will sometimes call the
|
|
||||||
* comparison routine to compare a value to itself. (At this writing only
|
|
||||||
* QNX 4 is known to do such silly things; we don't support QNX anymore,
|
|
||||||
* but perhaps the behavior still exists elsewhere.) Don't raise a bogus
|
|
||||||
* error in that case.
|
|
||||||
*/
|
*/
|
||||||
if (state->enforceUnique && !equal_hasnull && tuple1 != tuple2)
|
if (state->enforceUnique && !equal_hasnull)
|
||||||
{
|
{
|
||||||
Datum values[INDEX_MAX_KEYS];
|
Datum values[INDEX_MAX_KEYS];
|
||||||
bool isnull[INDEX_MAX_KEYS];
|
bool isnull[INDEX_MAX_KEYS];
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Some rather brain-dead implementations of qsort (such as the one in QNX 4)
|
||||||
|
* will sometimes call the comparison routine to compare a value to itself,
|
||||||
|
* but we always use our own implementation, which does not.
|
||||||
|
*/
|
||||||
|
Assert(tuple1 != tuple2);
|
||||||
|
|
||||||
index_deform_tuple(tuple1, tupDes, values, isnull);
|
index_deform_tuple(tuple1, tupDes, values, isnull);
|
||||||
ereport(ERROR,
|
ereport(ERROR,
|
||||||
(errcode(ERRCODE_UNIQUE_VIOLATION),
|
(errcode(ERRCODE_UNIQUE_VIOLATION),
|
||||||
@ -3070,9 +3072,8 @@ comparetup_index_btree(const SortTuple *a, const SortTuple *b,
|
|||||||
|
|
||||||
/*
|
/*
|
||||||
* If key values are equal, we sort on ItemPointer. This does not affect
|
* If key values are equal, we sort on ItemPointer. This does not affect
|
||||||
* validity of the finished index, but it offers cheap insurance against
|
* validity of the finished index, but it may be useful to have index scans
|
||||||
* performance problems with bad qsort implementations that have trouble
|
* in physical order.
|
||||||
* with large numbers of equal keys.
|
|
||||||
*/
|
*/
|
||||||
{
|
{
|
||||||
BlockNumber blk1 = ItemPointerGetBlockNumber(&tuple1->t_tid);
|
BlockNumber blk1 = ItemPointerGetBlockNumber(&tuple1->t_tid);
|
||||||
@ -3120,9 +3121,8 @@ comparetup_index_hash(const SortTuple *a, const SortTuple *b,
|
|||||||
|
|
||||||
/*
|
/*
|
||||||
* If hash values are equal, we sort on ItemPointer. This does not affect
|
* If hash values are equal, we sort on ItemPointer. This does not affect
|
||||||
* validity of the finished index, but it offers cheap insurance against
|
* validity of the finished index, but it may be useful to have index scans
|
||||||
* performance problems with bad qsort implementations that have trouble
|
* in physical order.
|
||||||
* with large numbers of equal keys.
|
|
||||||
*/
|
*/
|
||||||
tuple1 = (IndexTuple) a->tuple;
|
tuple1 = (IndexTuple) a->tuple;
|
||||||
tuple2 = (IndexTuple) b->tuple;
|
tuple2 = (IndexTuple) b->tuple;
|
||||||
|
Loading…
Reference in New Issue
Block a user