On 2019-10-29 03:33, Thomas Munro wrote:
> Seems to work as described with -E UTF-8, but it fails with clusters
> using -E SQL_ASCII. That causes the pg_upgrade check to fail on
> machines where that is the default encoding chosen by initdb (where
> unpatched master succeeds):
>
> pg_restore: creating COLLATION "pg_catalog.af-NA-x-icu"
> pg_restore: while PROCESSING TOC:
> pg_restore: from TOC entry 1700; 3456 12683 COLLATION af-NA-x-icu tmunro
> pg_restore: error: could not execute query: ERROR: collation
> "pg_catalog.af-NA-x-icu" for encoding "SQL_ASCII" does not exist
> Command was: ALTER COLLATION pg_catalog."af-NA-x-icu" OWNER TO tmunro;
This could be addressed by using is_encoding_supported_by_icu() in
pg_dump to filter out collations with unsupported encodings.
However, the more I look at this whole problem, I'm wondering whether it
wouldn't be preferable to avoid this whole mess by just not creating any
collations in initdb. What do you think?
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services