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
