Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values
Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Daniel Verite <daniel@manitou-mail.org>, Peter Geoghegan <pg@bowt.ie>,
PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-08-07T22:00:23Z
Lists: pgsql-bugs, pgsql-hackers
On 8/7/17 15:29, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes: >> On 8/7/17 13:30, Tom Lane wrote: >>> ... but what became of the af-NA and af-ZA collations? > >> This was already mentioned here: >> https://www.postgresql.org/message-id/93ef952f-40d4-24ce-bc62-97cc49a565ab@2ndquadrant.com > > Well, the fact that they're "redundant" doesn't really help you if > you can't pg_upgrade because the collation name you chose in v10 is > not present in initdb's results in v11. So this is still a serious > issue to my mind. It has never been the case that there is a guarantee that a new operating system environment will have the same or more collations available as an earlier version. Even glibc removes or renames locales. The way pg_upgrade works, it will presumably detect that during the schema dump/restore, so you should get a proper error message. In this particular case, you can create user-defined collations to fill in the missing names if you want. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Reject use of ucol_strcollUTF8() before ICU 53
- d6391b03b302 10.0 landed
-
Rethink behavior of pg_import_system_collations().
- 0b13b2a7712b 10.0 cited
-
Faster expression evaluation and targetlist projection.
- b8d7f053c5c2 10.0 cited