On Wed, Feb 15, 2017 at 9:17 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: >> Clearly when you upgrade your system from (say) Debian 8 to Debian 9 >> and the ICU major version changes we expect to have to REINDEX, but >> does anyone know if such data changes are ever pulled into the minor >> version package upgrades you get from regular apt-get update of (say) >> a Debian 8 or CentOS 7 or FreeBSD 11 system? In other words, do we >> expect collversion changes to happen basically any time in response to >> regular system updates, or only when you're doing a major upgrade of >> some kind, as the above-quoted documentation patch implies? > > Stable operating systems shouldn't do major library upgrades, so I feel > pretty confident about this.
There is one case where it *is* appropriate for a bugfix release of ICU to bump collator version: When there was a bug in the collator itself, leading to broken binary blobs [1]. We should make the user REINDEX when this happens. I think that ICU may well do this in point releases, which is actually a good thing. So, it seems like a good idea to test that there is no change, in a place like check_strxfrm_bug(). In my opinion, we should LOG a complaint in the event of a mismatch rather than refusing to start the server, since there probably isn't that much chance of the user being harmed by the bug. The cost of not starting the server properly until a REINDEX finishes or similar looks particularly unappealing when one considers that the app was probably affected by any corruption for weeks or months before the ICU update enabled its detection. [1] http://userguide.icu-project.org/collation/api#TOC-Sort-Key-Features -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
