Re: EDB builds Postgres 13 with an obsolete ICU version - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: EDB builds Postgres 13 with an obsolete ICU version
Date
Msg-id 20200814164235.GC25694@momjian.us
Whole thread Raw
In response to Re: EDB builds Postgres 13 with an obsolete ICU version  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Implement a new data type
Next
From: Tom Lane
Date:
Subject: Re: Parallel query hangs after a smart shutdown is issued