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

  1. Reject use of ucol_strcollUTF8() before ICU 53

  2. Rethink behavior of pg_import_system_collations().

  3. Faster expression evaluation and targetlist projection.