On 3/26/2019 9:45 AM, Christoph Berg wrote: > 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 > installations.
I suspect this is why MySQL keeps a whole zoo of collations internally that never change. >>> 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" > answer. > > 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. Is there a way upon next (re)start to have a startup script check for this case and reindex automatically then - at the expense of a hugely enlarged downtime? Say, with a flag file that keeps the glibc major version at last restart time around - for the first iteration on this? That's at least better than silent data corruption, even if still disruptive. On the other hand I guess you'd need to start the cluster for serving anyway for reindex to work and would then serve broken data in the meantime, too? Kind regards Philipp Kern
