Re: EDB builds Postgres 13 with an obsolete ICU version

On Tue, Aug 18, 2020 at 11:24 AM Dave Page <dpage(at)pgadmin(dot)org> wrote:

>
>
> On Mon, Aug 17, 2020 at 7:23 PM Bruce Momjian <bruce(at)momjian(dot)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 agree it definitely could, but I'm not sure I see any case where it would
actually be slower than the alternative (which would be dump/reload).

I'm also willing to say that given that (1) the windows installers don't
provide a way to do it automatically, and (2) the "commandline challenge"
of running pg_upgrade on WIndows in general, I bet there's a larger
percentage of users who are using dump/reload rather than pg_upgrade on
Windows than on other platforms already in the first place.

> 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.
>

My guess would be in the other direction :) But in particular, the vast
majority probably don't care at all, because they're not using ICU
collations.

It might be a slightly larger percentage on Windows who use it, but I'm
willing to bet it's still quite low.

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.
>

It does -- and we track it in pg_collation at this point.

I think the part that Michael is referring to is we don't track enough
details on a per-index basis. The suggested changes (in the separate
thread) are to get rid of it from pg_collation and move it to a per-object
dependency.

(And fwiw contains a patch to pg_upgrade to at least give it the ability to
for all old indexes say "i know that my icu is compatible". But yeah, the
full functionality won't be available until upgrading *from* 14)

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>