Re: Collation version tracking for macOS

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Jeremy Schneider <schneider(at)ardentperf(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, "Finnerty, Jim" <jfinnert(at)amazon(dot)com>, "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-01 10:33:29
Message-ID: 9f93a7b9-d144-9e48-40ef-36f7593e425e@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.10.22 03:22, Thomas Munro wrote:
> Suppose your pgdata encounters a PostgreSQL linked against a later ICU
> library, most likely after an OS upgrade or migratoin, a pg_upgrade,
> or via streaming replication. You might get a new error "can't find
> ICU collation 'en' with version '153.14'; HINT: install missing ICU
> library version", and somehow you'll have to work out which one might
> contain 'en' v153.14 and install it with apt-get etc. Then it'll
> magically work: your postgres linked against (say) 71 will happily
> work with the dlopen'd 67. This is enough if you want to stay on 67
> until the heat death of the universe. So far so good.

What I'm wondering is where those ICU installations are going to come
from. In order for this project to be viable, we would need to convince
some combination of ICU maintainers, OS packagers, and PGDG packagers to
provide and maintain five year's worth of ICU packages (yearly releases
AFAICT). Is that something we are willing to get into?

(Even to test this I need to figure out where to get another ICU
installation from. I'll try how easy manual installations are.)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anton A. Melnikov 2022-11-01 10:36:15 Re: [PATCH] Backport perl tests for pg_upgrade from 322becb60
Previous Message Etsuro Fujita 2022-11-01 10:24:36 Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit