讨论： Collations in PostgreSQL: libc, ICU and the builtin provider, and why a library upgrade can corrupt an index

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-16

暂无译文，显示原文。 原文

Concrete instances of the library-upgrade warning, and the check that finds the damage. The largest recent break was glibc 2.28 (2018), which reworked the collation data for most locales; databases moved from Debian 9 to 10 or from Ubuntu 18.04 to 20.04 with a libc default collation had text indexes whose order no longer matched, and PostgreSQL has recorded libc collation versions since 13 so that the mismatch is at least reported. An index that is already inconsistent is not found by `pg_collation_actual_version`, which compares recorded versions only; `pg_amcheck` (PostgreSQL 14 and later) or the `amcheck` extension's `bt_index_check` verifies the actual B-tree order and reports the corruption before a query returns wrong rows. Version facts for the provider choice: the `builtin` provider with `C.UTF-8` is PostgreSQL 17, `PG_UNICODE_FAST` is 18, and the 18 release notes list support for `LIKE` with nondeterministic collations, which removes one item from the article's list of their limits. Finally, `pg_dump` and restore, unlike `pg_upgrade`, rebuild every index on the target's libraries and therefore never carry the mismatch across.