Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc5a0325

Browse files
committed
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 previouslyobserved to affect only QNX 4, so it seems sufficiently to assert thatit isn't broken rather than retesting. Also, update a few comments toclarify why it's valuable to retain a tie-break rule based on CTIDduring index builds.Peter Geoghegan, with slight tweaks by me.
1 parent2d1371d commitc5a0325

File tree

1 file changed

+12
-12
lines changed

1 file changed

+12
-12
lines changed

‎src/backend/utils/sort/tuplesort.c

Lines changed: 12 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -3047,17 +3047,19 @@ comparetup_index_btree(const SortTuple *a, const SortTuple *b,
30473047
* sort algorithm wouldn't have checked whether one must appear before the
30483048
* other.
30493049
*
3050-
* Some rather brain-dead implementations of qsort will sometimes call the
3051-
* comparison routine to compare a value to itself. (At this writing only
3052-
* QNX 4 is known to do such silly things; we don't support QNX anymore,
3053-
* but perhaps the behavior still exists elsewhere.) Don't raise a bogus
3054-
* error in that case.
30553050
*/
3056-
if (state->enforceUnique&& !equal_hasnull&&tuple1!=tuple2)
3051+
if (state->enforceUnique&& !equal_hasnull)
30573052
{
30583053
Datumvalues[INDEX_MAX_KEYS];
30593054
boolisnull[INDEX_MAX_KEYS];
30603055

3056+
/*
3057+
* Some rather brain-dead implementations of qsort (such as the one in QNX 4)
3058+
* will sometimes call the comparison routine to compare a value to itself,
3059+
* but we always use our own implementation, which does not.
3060+
*/
3061+
Assert(tuple1!=tuple2);
3062+
30613063
index_deform_tuple(tuple1,tupDes,values,isnull);
30623064
ereport(ERROR,
30633065
(errcode(ERRCODE_UNIQUE_VIOLATION),
@@ -3070,9 +3072,8 @@ comparetup_index_btree(const SortTuple *a, const SortTuple *b,
30703072

30713073
/*
30723074
* If key values are equal, we sort on ItemPointer. This does not affect
3073-
* validity of the finished index, but it offers cheap insurance against
3074-
* performance problems with bad qsort implementations that have trouble
3075-
* with large numbers of equal keys.
3075+
* validity of the finished index, but it may be useful to have index scans
3076+
* in physical order.
30763077
*/
30773078
{
30783079
BlockNumberblk1=ItemPointerGetBlockNumber(&tuple1->t_tid);
@@ -3120,9 +3121,8 @@ comparetup_index_hash(const SortTuple *a, const SortTuple *b,
31203121

31213122
/*
31223123
* If hash values are equal, we sort on ItemPointer. This does not affect
3123-
* validity of the finished index, but it offers cheap insurance against
3124-
* performance problems with bad qsort implementations that have trouble
3125-
* with large numbers of equal keys.
3124+
* validity of the finished index, but it may be useful to have index scans
3125+
* in physical order.
31263126
*/
31273127
tuple1= (IndexTuple)a->tuple;
31283128
tuple2= (IndexTuple)b->tuple;

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp