Re: Q: error on updating collation version information

Am Sun, Dec 04, 2022 at 10:09:47AM -0800 schrieb Adrian Klaver:

> >>following an ICU upgrade, collations in a stock Debian PG 15.1
> >>cluster now have divergent version information in pg_collations.
> >
> >Correction: this is following a libc upgrade 2.35 -> 2.36
>
> So to be clear this database is not using ICU, but collations from libc?

Sorry for the confusion.

This database carries collations from _both_ libc and ICU in
pg_collations.

The collation in question (br_FR(at)euro) is _not_ in use (as in
being depended on by any in-database object).

> How was the database installed?

stock Debian

apt-get install postgresql-15 (which gives 15.1)

followed by

CREATE DATABASE "gnumed_v22" with owner = "redacted :-)" template = "template1" encoding = 'unicode';

as "postgres".

> In first post you had:
>
> gnumed_v22=> select *, pg_encoding_to_char(collencoding) from pg_collation where
> collname = 'br_FR(at)euro';
> -[ RECORD 1 ]-------+-----------
> oid | 12413
> collname | br_FR(at)euro
> collnamespace | 11
> collowner | 10
> collprovider | c
> collisdeterministic | t
> collencoding | 16
> collcollate | br_FR(at)euro
> collctype | br_FR(at)euro
> colliculocale |
> collversion | 2.35
> pg_encoding_to_char | LATIN9
>
> where collprovider c means libc and collversion 2.35.

Yeah, that's when I figured that I misspoke about the ICU upgrade.

Yes, there was an ICU upgrade, and yes, it did affect
collations. Those I was able to fix up (the "reindex /
revalidate constraint / refresh collation version" dance).

There also was a libc upgrade which also affected locales.
Most of them were fixable by that dance but some popped up
(such as br_FR(at)euro) to not be "correctable" showing the
"does not exist for encoding" error.

Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B