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: /messages/by-id/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(-)
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:
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
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:
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