Horton

Re: Crash report for some ICU-52 (debian8) COLLATE and work_mem values

Peter Eisentraut <peter.eisentraut@2ndquadrant.com>

View thread View on postgr.es
From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Peter Geoghegan <pg@bowt.ie>, Daniel Verite <daniel@manitou-mail.org>, PostgreSQL mailing lists <pgsql-bugs@postgresql.org>
Date: 2017-08-14T15:08:00Z
Lists: pgsql-bugs, pgsql-hackers 
On 8/9/17 15:29, Robert Haas wrote:
> On Wed, Aug 9, 2017 at 2:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I suppose a different way to address this would be to make pg_upgrade
>> smart enough to deal with the situation, by creating ICU collations
>> that are used in the source installation but are missing from the
>> initdb-provided set in the target.
> 
> Yeah, that idea has some appeal.

I think the manual workflow would be that you initdb the target
instance, then log into the target instance to create the missing
collations, then run pg_upgrade.

While pg_upgrade could probably detect which collations are missing on
the target side, I don't think it follows that it can just create the
missing ones automatically.  Manual intervention would be necessary (and
desirable IMO) to analyze the situation.

-- 
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.