Bug 1152556 - RFE: detect --locale from old datadir automatically in `postgresql-setup --upgrade`
Summary: RFE: detect --locale from old datadir automatically in `postgresql-setup --up...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Orphan Owner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-10-14 12:08 UTC by udo.rader
Modified: 2024-11-27 01:54 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2014-10-14 12:52:53 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description udo.rader 2014-10-14 12:08:30 UTC
I recently switched the localed of my development laptop from en_US.utf8 to de_AT.utf8. After the switch and after some upgrades later, my postgres would not start anymore:

-----------CUT-----------
% systemctl start postgresql
Job for postgresql.service failed. See 'systemctl status postgresql.service' and 'journalctl -xn' for details.
Version-Release number of selected component (if applicable):
-----------CUT-----------

Which leads me to the following journalctl -x output

-----------CUT-----------
[...]
Oct 14 13:59:47 artio.bestsolution.at postgresql-check-db-dir[11400]: An old version of the database format was found.
Oct 14 13:59:47 artio.bestsolution.at postgresql-check-db-dir[11400]: Use "postgresql-setup upgrade" to upgrade to version 9.3.
Oct 14 13:59:47 artio.bestsolution.at postgresql-check-db-dir[11400]: See /usr/share/doc/postgresql/README.rpm-dist for more information.
Oct 14 13:59:47 artio.bestsolution.at systemd[1]: postgresql.service: control process exited, code=exited status=1
Oct 14 13:59:47 artio.bestsolution.at systemd[1]: Failed to start PostgreSQL database server.
[...]
-----------CUT-----------

% postgresql-setup upgrade 

... then fails as well, leaving this in /var/lib/pgsql/pgupgrade.log:

-----------CUT-----------
Performing Consistency Checks
[...]
lc_collate cluster values do not match:  old "en_US.UTF-8", new "de_DE.utf8"
Failure, exiting
[...]
-----------CUT-----------

unfortunately, no matter if I force LC_COLLATE or even LC_ALL to be en_US.UTF-8 or also export it, the upgrade still fails:

% LC_ALL=en_US.UTF-8 postgresql-setup upgrade
Upgrading database: failed
[...]

% export LC_ALL=en_US.UTF-8 && postgresql-setup upgrade
Upgrading database: failed
[...]

I can probably change my system locale to en_US.UTF-8 again, but that would cause some other sideeffects that I want to prevent.

Comment 1 udo.rader 2014-10-14 12:22:05 UTC
checking the bug list again, this seems to be closely related to #1007802.

And finally, I changed my locale to en_US again but postgresql-setup upgrade still fails with this very wonderful message in the upgrade log:

---------CUT--------
lc_collate cluster values do not match:  old "en_US.UTF-8", new "en_US.utf8"
Failure, exiting
---------CUT--------

Yes, indeed, the lowercasing is not equal to uppercase, but that seems to be very picky ...

Comment 2 Pavel Raiskup 2014-10-14 12:52:53 UTC
Thanks for the report.

(In reply to udo.rader from comment #1)
> checking the bug list again, this seems to be closely related to #1007802.
> 
> And finally, I changed my locale to en_US again but postgresql-setup upgrade
> still fails with this very wonderful message in the upgrade log:

Switching locale should not be necessary.  Try this:
PGSETUP_INITDB_OPTIONS="--locale=en_US.UTF-8" postgresql-setup upgrade

That was added as a part of bug #1052063.

> ---------CUT--------
> lc_collate cluster values do not match:  old "en_US.UTF-8", new "en_US.utf8"
> Failure, exiting
> ---------CUT--------
> 
> Yes, indeed, the lowercasing is not equal to uppercase, but that seems to be
> very picky ...

Truth, it is picky - this has been fixed upstream in master branch for some
time.  Upstream commit:
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=58274728fb8e087049

The fix did not get enough priority to be backpatched to upstream stable
branches, so I didn't backport to f20 (taking into account there exists
work-around).

For F21, however, I don't think that we get this fixed via rebase to 9.4 so
I'll probably backport (via the duplicate bug).

*** This bug has been marked as a duplicate of bug 1007802 ***

Comment 3 Pavel Raiskup 2014-10-14 13:20:36 UTC
Reopening - we really should deal with this issue (somehow), even for changes
like 'en_US.utf8' ~> 'de_AT.utf8';  without explicit --locale option.

Comment 4 Jaroslav Reznik 2015-03-03 17:04:18 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle.
Changing version to '22'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22

Comment 5 Fedora Admin user for bugzilla script actions 2021-07-01 15:37:03 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

Comment 6 FSA 2022-04-25 07:39:38 UTC
I am having similar problems. When installing PostgreSQL, I use LC_COLLATE=C and UTF-8 encoding. Developers recommend using C, because in this case, maximum performance and the same behavior on various operating systems (Linux, Mac OS, Windows) will be obtained: https://www.postgresql.org/docs/current/locale.html

When upgrading the database, the old settings are ignored. To perform an upgrade, you must specify parameters for initdb (specify the values that were used when initializing the database):
export PGSETUP_INITDB_OPTIONS="--locale=C --encoding=UTF-8"; postgresql-setup --upgrade

The LC_COLLATE and LC_CTYPE settings are determined when a database is created, and cannot be changed except by creating a new database!!!

Comment 7 Fedora Admin user for bugzilla script actions 2024-11-27 01:54:55 UTC
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.


Note You need to log in before you can comment on or make changes to this bug.