Re: Collation version tracking for macOS - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Collation version tracking for macOS
Date
Msg-id 9f93a7b9-d144-9e48-40ef-36f7593e425e@enterprisedb.com
Whole thread Raw
In response to Re: Collation version tracking for macOS  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Collation version tracking for macOS
List 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.)




pgsql-hackers by date:

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