On Fri, Aug 14, 2020 at 09:00:06AM -0400, Bruce Momjian wrote: > On Tue, Aug 11, 2020 at 02:58:30PM +0200, Magnus Hagander wrote: >> I assumed it had code for that stuff already. Mainly because I assumed it >> supported doing pg_upgrade, which requires similar things no? > > While pg_upgrade requires having the old and new cluster software in > place, I don't think it helps allowing different ICU versions for each > cluster. I guess you can argue that if you know the user is _not_ going > to be using pg_upgrade, then a new ICU version should be used for the > new cluster.
We have nothing in core, yet, that helps with this kind of problem with binary upgrades. In the last year, Julien and I worked on an upgrade case where a glibc upgrade was involved with pg_upgrade used for PG, and it could not afford the use of a new host to allow a logical dump/restore to rebuild the indexes from scratch. You can always run a "reindex -a" after the upgrade to be sure that no indexes are broken because of the changes with collation versions, but once you have to give the guarantee that an upgrade does not take longer than a certain amount of time, the reindex easily becomes the bottleneck. That's one motivation behind the recent work to add collation versions to pg_depend entries, which would lead to more filtering facilities for REINDEX on the backend to get for example the option to only reindex collation-sensitive indexes (imagine just a reindexdb --jobs with the collation filtering done at table-level, that would be fast, or a script doing this work generated by pg_upgrade). -- Michael
signature.asc
Description: PGP signature
