Glibc 2.28 breaks collation for PostgreSQL (and others?)
Hi,
with the update to glibc 2.28, collation aka sort ordering is
changing:
$ echo $LANG
de_DE.utf8
$ (echo 'a-a'; echo 'a a'; echo 'a+a'; echo 'aa') | sort
stretch:
aa
a a
a-a
a+a
buster:
a a
a+a
a-a
aa
A vast number of locales is affected, including en_US, possibly all of
them.
For PostgreSQL, this means that the ordering of indexes on disk is
becoming corrupt, and all "text" (varchar, char, ...) indexes need to
be rebuilt. (And worse, if that is not done immediately, the tables
might become corrupt because some tuples aren't index-visible anymore
due to the incorrect btree ordering.)
https://postgresql.verite.pro/blog/2018/08/27/glibc-upgrade.html
https://www.postgresql.org/message-id/9cbd8ba7-899f-4ed3-92b1-902b0d2456ae@manitou-mail.org
The PostgreSQL project is discussing how this could be handled inside
the database, but a) it's totally unclear how this could be detected
generically, not just for this set of test strings, and b) Debian
needs a fix now, not something that might appear in PostgreSQL 12 or 13.
I've been thinking about this for some time, and the best I could come
up so far is "raise a debconf note that people need to invoke REINDEX
DATABASE". The open question about this plan is, how should this note
be triggered.
Plan 1: Add a check if there are any postgresql clusters in
/etc/postgresql/, and raise the warning from locales.postinst and
locales-all.postinst.
Plan 2: Add a trigger to postgresql-common that checks if
locales(-all) are being upgraded, and raise the warning from there.
(This plan has the downside that we'd need to fix postgresql-common in
stretch to have the same check.)
Plan 1 looks much better.
I'm sorry that I didn't raise that earlier because I had hoped to come
up with some smarter solution that would take some burden from the
user having to run commands manually.
Does that make sense? Are there any options that I missed? Are there
any other packages affected? How do we proceed?
Christoph
Reply to: