Re: pg_upgrading to 10.1 corrupts (varchar,varchar) UNIQUE indices - Mailing list pgsql-general

From Peter Geoghegan
Subject Re: pg_upgrading to 10.1 corrupts (varchar,varchar) UNIQUE indices
Date
Msg-id CAH2-Wz=MOWayxuRvQ_EhH3Fvv9VMeEpP1xxYB+dvvZE-Fa0u-g@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrading to 10.1 corrupts (varchar,varchar) UNIQUE indices  (rihad <rihad@mail.ru>)
List pgsql-general
On Fri, Dec 22, 2017 at 4:16 PM, rihad <rihad@mail.ru> wrote:
> You mean they would have to bring back ICU support as an option? Ok, I'll
> try to report the problem.

The FreeBSD package previously contained a hacked-in ICU library,
meaning that the version of Postgres shipped with FreeBSD was
technically a fork, in order to compensate for the previous lack of
collations/locales in FreeBSD's libc. Now that FreeBSD has built-in
libc collations, and now that ICU is available as an option (a fully
recognized alternative "collation provider") in Postgres 10, it would
make sense for FreeBSD to "unfork", which is what I assume happened
here. As I said, it's not that much of a stretch to suppose that
pg_upgrade was overlooked, because at least everything else would work
fine.

The way that ICU was supported (which presumably changed with the
"unfork") is going to break Postgres assumptions about the
immutability of OS collations. IIRC, the forked code more or less
pretended that ICU functions were the actual OS libc collation
functions (which are assumed immutable). If I have everything right
here, this is more or less equivalent to a total behavioral change in
OS collations, even though the OS collation behavior apparently did
not change.

I'm currently feeling too lazy to check that I guessed right about all
of this, but somebody should look into it.

-- 
Peter Geoghegan


pgsql-general by date:

Previous
From: rihad
Date:
Subject: Re: pg_upgrading to 10.1 corrupts (varchar,varchar) UNIQUE indices
Next
From: rihad
Date:
Subject: Re: pg_upgrading to 10.1 corrupts (varchar,varchar) UNIQUE indices