Re: EDB builds Postgres 13 with an obsolete ICU version

On Mon, Aug 17, 2020 at 7:23 PM Bruce Momjian <bruce@momjian.us> wrote:

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. 

Not necessarily. It's likely that not all indexes use ICU collations, and you still save time loading what may be large amounts of data.

I agree though, that it *could* be slow.

I can see a lot more people being disappointed by this than
will be happy to have Postgres using a newer ICU library.

Quite possibly, hence my hesitation to push ahead with anything more than a simple test build at this time.

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?

I wasn't aware that ICU had the concept of collation versions internally (which Michael seems to have confirmed downthread). That would potentially make the number of users needing a reindex even smaller, but as you point out won't help us for years as we don't store it anyway.