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 <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
