Re: Glibc 2.28 breaks collation for PostgreSQL (and others?)
Re: Philipp Kern 2019-03-26 <[🔎] 66988de0-f9be-14c0-6b64-df64261fee18@philkern.de>
> I suspect this is why MySQL keeps a whole zoo of collations internally
> that never change.
DB2 and Oracle bundle ICU for that reason, afaict. (But bundling
software has other problems, as we all know...)
> 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?
We were thinking about doing something like that, but that doesn't
work for the general case - most libc upgrades do not break
everything, and reindexing would be overkill. It might help for the
2.28 upgrade, but getting this to work consistently would require lots
of scripting with lots of cornercases to cover. I don't think it is
possible to get this working reliably now, especially as we would need
to push that "fix" into stretch-proposed-updates as well. (Because
libc6 will likely be upgraded first, before the new postgresql-common
version could take action.)
> 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?
That's part of the problem, yes.
Christoph
Reply to: