From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Preserve versions of initdb-created collations in pg_upgrade |
Date: | 2019-12-21 06:38:16 |
Message-ID: | 94946f2f-1f4a-8874-53b4-5a480f6e25d1@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2019-12-21 06:47:29 | Optimize update of tables with generated columns |
Previous Message | Tom Lane | 2019-12-21 03:17:20 | Re: pgsql: Superuser can permit passwordless connections on postgres_fdw |