Re: Preserve versions of initdb-created collations in pg_upgrade

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

In response to

Responses

Browse pgsql-hackers by date

  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