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

Reply via email to