Description of problem: Attempting to upgrade a RHV 4.1 installation to 4.2 fails with an error during the PostgreSQL upgrade. The file /var/lib/pgsql/upgrade_rh-postgresql95-postgresql.log contains the error: lc_collate values for database "postgres" do not match: old "en_GB.UTF-8", new "en_US.UTF-8" The databases on the server do indeed have mixed locales: postgres=# \l List of databases Name | Owner | Encoding | Collate | Ctype | Access privileges ----------------------+----------------------+----------+-------------+-------------+----------------------- engine | engine | UTF8 | en_US.UTF-8 | en_US.UTF-8 | ovirt_engine_history | ovirt_engine_history | UTF8 | en_US.UTF-8 | en_US.UTF-8 | postgres | postgres | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | template0 | postgres | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres template1 | postgres | UTF8 | en_GB.UTF-8 | en_GB.UTF-8 | =c/postgres + | | | | | postgres=CTc/postgres (5 rows) The system locale is as follows: # locale LANG=en_GB.UTF-8 LC_CTYPE="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_PAPER="en_GB.UTF-8" LC_NAME="en_GB.UTF-8" LC_ADDRESS="en_GB.UTF-8" LC_TELEPHONE="en_GB.UTF-8" LC_MEASUREMENT="en_GB.UTF-8" LC_IDENTIFICATION="en_GB.UTF-8" LC_ALL= Version-Release number of selected component (if applicable): Upgrade from 4.1 to 4.2 How reproducible: Every time Steps to Reproduce: 1. Unsure. The existing RHV system was upgraded from 4.0 to 4.1, but I'm not sure how the original locale settings were created. Actual results: Upgrade failure Expected results: Upgrade success Additional info:
I believe many of our customers will be affected, by the unfiltered DB check. Can you please assign urgently? I believe this is an async candidate.
(In reply to Peter McGowan from comment #0) > Steps to Reproduce: > 1. Unsure. The existing RHV system was upgraded from 4.0 to 4.1, but I'm not > sure how the original locale settings were created. This is the hard part :-( I'd expected this bug to be fixed by the fix to bug 1528371 (that is, close it as duplicate of it), but apparently it's not, but not sure how to reproduce. Please attach engine-setup logs, for a start, so that we can see we passed the correct/intended options to postgresql-setup. If we did, we need to understand how to reproduce.
Restoring lost needinfo
Created attachment 1437871 [details] Engine setup log
As far as I can remember, the RHV 4.0 system was a clean RHEL 7 installed on 2017-12-05, expressly to upgrade a RHEV 3.6 environment. I would have installed a fairly basic RHEL 7 installation as suggested by the upgrade docs, then performed the steps to export the old 3.6 databases and install RHV 4.0. I don't remember explicitly setting the locale but I installed the RHEL 7 system using the GUI installer, so it was probably set by anaconda when I set my timezone.
Thanks. The fix for 1528371 didn't work - e.g., we didn't check lc_collate. Looking
OK, now I understand. Seems like the fix for bug 1528371 for the 4.2 branch was broken. Sorry, must have been something in the way I handled the back-porting. Will fix soon.
Engine upgraded with postgres database in SQL_ASCII or en_GB.UTF-8 encoding with success. verified in ovirt-engine-4.2.3.8-0.1.el7.noarch
BZ<2>Jira Resync