On Mon, Aug 17, 2020 at 04:55:13PM +0100, Dave Page wrote:
> That was more if the installer actually handles the whole chain. It clearly
> doesn't today (since it doesn't support upgrades), I agree this might
> definitely be overkill. But then also I don't really see the problem with
> just putting a new version of ICU in with the newer versions of PostgreSQL.
> That's just puts the user in the same position as they are with any other
> platform wrt manual pg_upgrade runs.
>
> Well we can certainly do that if everyone is happy in the knowledge that it'll
> mean pg_upgrade users will need to reindex if they've used ICU collations.
>
> Sandeep; can you have someone do a test build with the latest ICU please (for
> background, this would be with the Windows and Mac installers)? If noone
> objects, we can push that into the v13 builds before GA. We'd also need to
> update the README if we do so.
Woh, we don't have any support in pg_upgrade to reindex just indexes
that use ICU collations, and frankly, if they have to reindex, they
might decide that they should just do pg_dump/reload of their cluster at
that point because pg_upgrade is going to be very slow, and they will be
surprised. I can see a lot more people being disappointed by this than
will be happy to have Postgres using a newer ICU library.
Also, is it the ICU library version we should be tracking for reindex,
or each _collation_ version? If the later, do we store the collation
version for each index?
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EnterpriseDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee