Re: Florian Weimer 2019-03-25 <>
> > 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.)
> That's fairly normal in a glibc update.  glibc upstream prefers it
> this way.  I've discussed it several times with other glibc
> maintainers.

Changes are normal. What's not normal here is the scale of the
changes, indexes will break for virtually all users.

> My understanding is that ICU provides versioned collation tables,
> which would allow you to avoid this issue.
>   <>

Unfortunately not. PostgreSQL supports ICU, but not as the global
locale for clusters/databases, which is still libc only. And even if
it was supported, it's not the default, and we are still breaking all

> > 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.
> That might not work for unique indices because locale data changes
> could cause strings to sort the same that were distinct before the
> update.

Well, that's not an argument for silently doing nothing. And I doubt
that this case even exists, for any two distinct strings, the
collation should output a consistent "less than" or "greater than"

I forgot to mention Plan 3: Mention this in the release notes.
That should be done anyway, the question being if that is enough.
My suspicion is that few people actually read the release notes, so
some notification from inside the system would be needed as well.
Be it a debconf note, and/or a NEWS.Debian entry somewhere.

I deem this to be release-critical for PostgreSQL users. The reason
I'm asking here is to get input which plan is the best.


Reply via email to