Thread: pgsql: pg_upgrade: copy locale and encoding information to new cluster.
pg_upgrade: copy locale and encoding information to new cluster. Previously, pg_upgrade checked that the old and new clusters were compatible, including the locale and encoding. But the new cluster was just created, and only template0 from the new cluster will be preserved (template1 and postgres are both recreated during the upgrade process). Because template0 is not sensitive to locale or encoding, just update the pg_database entry to be the same as template0 from the original cluster. This commit makes it easier to change the default initdb locale or encoding settings without causing needless incompatibilities. Discussion: https://postgr.es/m/d62b2874-729b-d26a-2d0a-0d64f509eca4@enterprisedb.com Reviewed-by: Peter Eisentraut Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/9637badd9f9209166140eb567602e91699dd2ffb Modified Files -------------- src/bin/pg_upgrade/Makefile | 2 + src/bin/pg_upgrade/check.c | 160 --------------------------------- src/bin/pg_upgrade/info.c | 69 ++++++++++---- src/bin/pg_upgrade/meson.build | 1 + src/bin/pg_upgrade/pg_upgrade.c | 62 +++++++++++++ src/bin/pg_upgrade/pg_upgrade.h | 12 ++- src/bin/pg_upgrade/t/002_pg_upgrade.pl | 69 +++++++++++++- 7 files changed, 192 insertions(+), 183 deletions(-)
Re: pgsql: pg_upgrade: copy locale and encoding information to new cluster.
From
Andrew Dunstan
Date:
On 2023-03-09 Th 11:40, Jeff Davis wrote:
pg_upgrade: copy locale and encoding information to new cluster. Previously, pg_upgrade checked that the old and new clusters were compatible, including the locale and encoding. But the new cluster was just created, and only template0 from the new cluster will be preserved (template1 and postgres are both recreated during the upgrade process). Because template0 is not sensitive to locale or encoding, just update the pg_database entry to be the same as template0 from the original cluster. This commit makes it easier to change the default initdb locale or encoding settings without causing needless incompatibilities.
This looks like it broke cross version upgrade testing. Old versions don't have datlocprovider.
Performing Consistency Checks ----------------------------- Checking cluster versions ok SQL command failed SELECT encoding, datlocprovider, datcollate, datctype, daticulocale FROM pg_catalog.pg_database WHERE datname='template0' ERROR: column "datlocprovider" does not exist LINE 1: SELECT encoding, datlocprovider, datcollate, datctype... ^ Failure, exiting cheers andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com
On Thu, 2023-03-09 at 12:21 -0500, Andrew Dunstan wrote:
> This looks like it broke cross version upgrade testing. Old versions
> don't have datlocprovider.
Thank you, fixing. Just waiting for some CI tests.
Regards,
Jeff Davis
On Thu, 2023-03-09 at 09:35 -0800, Jeff Davis wrote: > On Thu, 2023-03-09 at 12:21 -0500, Andrew Dunstan wrote: > > This looks like it broke cross version upgrade testing. Old > > versions > > don't have datlocprovider. > > Thank you, fixing. Just waiting for some CI tests. I fixed most of the problems, but I'm still seeing a failure on crake: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2023-03-09%2019%3A37%3A04&stg=xversion-upgrade-REL9_4_STABLE-HEAD It seems only the 94 upgrade is failing, and the message seems unrelated to my change: "could not load library "$libdir/uuid-ossp": ERROR: could not access file "$libdir/uuid-ossp": No such file or directory In database: contrib_regression_uuid-ossp" Is that a transient failure? I tried locally testing the upgrades, but it seems like the version of master before my change (8dff2f224f) also fails the pg_upgrade test for all versions earlier than 10. I assume there are some extra steps to make the test work for earlier versions, but I haven't looked deeply yet. Regards, Jeff Davis
Re: pgsql: pg_upgrade: copy locale and encoding information to new cluster.
From
Andrew Dunstan
Date:
On 2023-03-09 Th 17:21, Jeff Davis wrote:
On Thu, 2023-03-09 at 09:35 -0800, Jeff Davis wrote:On Thu, 2023-03-09 at 12:21 -0500, Andrew Dunstan wrote:This looks like it broke cross version upgrade testing. Old versions don't have datlocprovider.Thank you, fixing. Just waiting for some CI tests.I fixed most of the problems, but I'm still seeing a failure on crake: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2023-03-09%2019%3A37%3A04&stg=xversion-upgrade-REL9_4_STABLE-HEAD It seems only the 94 upgrade is failing, and the message seems unrelated to my change: "could not load library "$libdir/uuid-ossp": ERROR: could not access file "$libdir/uuid-ossp": No such file or directory In database: contrib_regression_uuid-ossp" Is that a transient failure?
I think it's a different issue, probably related to the fact that crake is taking meson for a walk.
cheers
andrew
-- Andrew Dunstan EDB: https://www.enterprisedb.com