Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)

[Philipp Kern <pkern@debian.org>]

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