On Fri, Aug 14, 2020 at 10:23:27PM +0900, Michael Paquier wrote: > 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).
Agreed --- only a small percentage of indexes are affected by collations, and it would be great if we could tell users how to easily identify them. -- Bruce Momjian <br...@momjian.us> https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
