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

Commit3df9c37

Browse files
committed
Disable abbreviated keys for string-sorting in non-C locales.
Unfortunately, every version of glibc thus far tested has bugs wherebystrcoll() ordering does not match strxfrm() ordering as required bythe standard. This can result in, for example, corrupted indexes.Disabling abbreviated keys in these cases slows down non-C-collationstring sorting considerably, but there seems to be no practicalalternative. Users who are confident that their libc implementationsare solid in this regard can re-enable the optimization by compilingwith TRUST_STRXFRM.Users who have built indexes using PostgreSQL 9.5 or PostgreSQL 9.5.1should REINDEX if there is a possibility that they may have beenaffected by this problem.Report by Marc-Olaf Jaschke. Investigation mostly by Tom Lane, withhelp from Peter Geoghegan, Noah Misch, Stephen Frost, and me. Patchby me, reviewed by Peter Geoghegan and Tom Lane.
1 parent3151f16 commit3df9c37

File tree

1 file changed

+23
-10
lines changed

1 file changed

+23
-10
lines changed

‎src/backend/utils/adt/varlena.c

Lines changed: 23 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -1832,17 +1832,30 @@ varstr_sortsupport(SortSupport ssup, Oid collid, bool bpchar)
18321832
}
18331833

18341834
/*
1835-
* It's possible that there are platforms where the use of abbreviated
1836-
* keys should be disabled at compile time. Having only 4 byte datums
1837-
* could make worst-case performance drastically more likely, for example.
1838-
* Moreover, Darwin's strxfrm() implementations is known to not
1839-
* effectively concentrate a significant amount of entropy from the
1840-
* original string in earlier transformed blobs. It's possible that other
1841-
* supported platforms are similarly encumbered. However, even in those
1842-
* cases, the abbreviated keys optimization may win, and if it doesn't,
1843-
* the "abort abbreviation" code may rescue us. So, for now, we don't
1844-
* disable this anywhere on the basis of performance.
1835+
* Unfortunately, it seems that abbreviation for non-C collations is
1836+
* broken on many common platforms; testing of multiple versions of glibc
1837+
* reveals that, for many locales, strcoll() and strxfrm() do not return
1838+
* consistent results, which is fatal to this optimization. While no
1839+
* other libc other than Cygwin has so far been shown to have a problem,
1840+
* we take the conservative course of action for right now and disable
1841+
* this categorically. (Users who are certain this isn't a problem on
1842+
* their system can define TRUST_STRXFRM.)
1843+
*
1844+
* Even apart from the risk of broken locales, it's possible that there
1845+
* are platforms where the use of abbreviated keys should be disabled at
1846+
* compile time. Having only 4 byte datums could make worst-case
1847+
* performance drastically more likely, for example. Moreover, Darwin's
1848+
* strxfrm() implementations is known to not effectively concentrate a
1849+
* significant amount of entropy from the original string in earlier
1850+
* transformed blobs. It's possible that other supported platforms are
1851+
* similarly encumbered. So, if we ever get past disabling this
1852+
* categorically, we may still want or need to disable it for particular
1853+
* platforms.
18451854
*/
1855+
#ifndefTRUST_STRXFRM
1856+
if (!collate_c)
1857+
abbreviate= false;
1858+
#endif
18461859

18471860
/*
18481861
* If we're using abbreviated keys, or if we're using a locale-aware

0 commit comments

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