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