PostgreSQL v15.12 fails to perform PG_UPGRADE from v13 and v9 on Windows - Mailing list pgsql-bugs

From Ben Caspi
Subject PostgreSQL v15.12 fails to perform PG_UPGRADE from v13 and v9 on Windows
Date
Msg-id CABv1Mx6uBG1OJX3+FHewqCoGtGuQqsLniB47WUrrt8sd1PDK1Q@mail.gmail.com
Whole thread Raw
Responses Re: PostgreSQL v15.12 fails to perform PG_UPGRADE from v13 and v9 on Windows
List pgsql-bugs
Hello!

We have an environment with numerous client Windows machines. The machines have PSQL v9.6/v13.13/v15.6 installed.
We've been working on slowly upgrading the 9/13 machines to use PSQL 15, which has been going smoothly until recently.

We've been made aware of an issue with 15.6 which prompted us to change our latest version to 15.12 instead (we can't go past 15 due to many of our machines being Windows Server 2016, which from our understanding is not supported in v16 and onwards).

Upgrading our 15.6 machines to 15.12 has been going smoothly.
However, running PG_UPGRADE on PSQL v9.6/13.13 to v15.12 has been failing.

This is the error message:
lc_collate values for database "template1" do not match:  old "English_United States.1252", new "en-US"

Upon investigation, we came to understand that the PSQL v9.6/v13.13 config contains the following configuration by default:
lc_messages = 'English_United States.1252'
lc_monetary = 'English_United States.1252'
lc_numeric = 'English_United States.1252'
lc_time = 'English_United States.1252'

But when installing PSQL 15.12 it's changed to:
lc_messages = 'en-US'
lc_monetary = 'en-US'
lc_numeric = 'en-US'
lc_time = 'en-US'

Is a failure in upgrading to this version intended?
We can workaround this issue by upgrading to 15.6 and then to 15.12, but I'd like to avoid this solution as it lengthens potential downtime for our clients.

Any help would be appreciated.
Thanks!

--

photo

Ben Caspi
DevOps Engineer

www.aidoc.com  |  benc@aidoc.com

linkedin

twitter

App Banner Image

 
__tpx__

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #18857: Abnormal string comparison results
Next
From: Andrei Lepikhov
Date:
Subject: Re: BUG #18854: PostgreSQL chooses a suboptimal execution plan when using a specific WHERE filter