Re: Collation version tracking for macOS

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Jeremy Schneider <schneider(at)ardentperf(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Nasby, Jim" <nasbyj(at)amazon(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Collation version tracking for macOS
Date: 2022-11-29 20:59:47
Message-ID: 12a7c9ddd5c44003869a114d0b5326fec27b2477.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 2022-11-30 at 08:41 +1300, Thomas Munro wrote:
> In terms of user experience, I think that might mean that users of
> 'zh' who encounter warnings after a minor upgrade would therefore
> really only have the options of REFRESHing and rebuilding, or
> downgrading the package, because there's no way for us to access the
> older version.  Users of 'en' probably only encounter collversion
> changes when moving between OS releases with an ICU major version
> change, and then the various schemes in this thread can help them
> avoid the need to rebuild, until they eventually want to, if ever.

I installed the first minor release for each major, and got some new
tables. I think we can all agree that it's a lot easier to work with
information once it's in table form.

Here's what I found for the 'ar' locale (firstminor/lastminor are the
icu library versions, firstcollversion/lastcollversion are their
respective collation versions for the given locale):

firstminor | lastminor | firstcollversion | lastcollversion
------------+-----------+------------------+-----------------
60.1 | 60.3 | 153.80.32 | 153.80.32.1
64.1 | 64.2 | 153.96.35 | 153.97.35.8
68.1 | 68.2 | 153.14.38 | 153.14.38.8
(3 rows)

For 'en':

firstminor | lastminor | firstcollversion | lastcollversion
------------+-----------+------------------+-----------------
64.1 | 64.2 | 153.96 | 153.97
(1 row)

And for 'zh':

firstminor | lastminor | firstcollversion | lastcollversion
------------+-----------+------------------+-----------------
60.1 | 60.3 | 153.80.32 | 153.80.32.1
64.1 | 64.2 | 153.96.35 | 153.97.35.8
68.1 | 68.2 | 153.14.38 | 153.14.38.8
(3 rows)

It looks like collation versions do change in minor releases. It looks
like it's *not* safe to lock a collation to a major version *if* that
major version could be updated to a new minor. And we can't lock to a
minor, as I said earlier. Therefore, once we lock a collation down to a
major release, we better keep that in the icu_library_path, and never
touch it, and never install a new minor for that major.

Then again, maybe some of these are just about how the version is
reported... maybe 153.80.32 and 153.80.32.1 are really the same
version? But 64.1 -> 64.2 looks like a real difference.

I suppose the next step is to test with actual data and find
differences?

--
Jeff Davis
PostgreSQL Contributor Team - AWS

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-11-29 21:12:21 Re: [PoC] Federated Authn/z with OAUTHBEARER
Previous Message Tom Lane 2022-11-29 20:46:07 Re: Slow standby snapshot