FS#75665 - [postgresql] replace en_US.UTF-8 with C.UTF-8 in postgresql-check-db-dir

Attached to Project: Arch Linux
Opened by nl6720 (nl6720) - Monday, 22 August 2022, 07:25 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:27 GMT
Task Type General Gripe
Category Packages: Extra
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
When /var/lib/postgres/data is empty, the package install script will run postgresql-check-db-dir (a custom Arch script: https://github.com/archlinux/svntogit-packages/blob/packages/postgresql/trunk/postgresql-check-db-dir ) which prints:

"/var/lib/postgres/data" is missing or empty. Use a command like
su - postgres -c "initdb --locale en_US.UTF-8 -D '/var/lib/postgres/data'"
with relevant options, to initialize the database cluster.

Since the en_US.UTF-8 locale requires generating it before use, it should be better to instead suggest the C.UTF-8 locale that's shipped by default.


Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any
postgresql 14.5-1


Steps to reproduce:
# pacman -S postgresql
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:27 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/postgresql/issues/3
Comment by nl6720 (nl6720) - Saturday, 18 March 2023, 13:46 GMT
Another advantage of C.UTF-8 is that it won't trigger the "collation version mismatch" warning after glibc or icu updates (  FS#77445  ).
Comment by loqs (loqs) - Sunday, 19 March 2023, 21:57 GMT
> Another advantage of C.UTF-8 is that it won't trigger the "collation version mismatch" warning after glibc or icu updates (  FS#77445  ).
How does switching the locale stop the version mismatch? As I understand it the comparison is between the runtime version of glibc which is used a proxy for the collation version of glibc provided collations and the version recorded in the pg_collation relation for each collation. The version recorded is the glibc version from when initdb is run or the collation was refreshed. This also means the fix from  FS#77445  rebuilding postgresql after a glibc package update is pointless as the check is runtime not buildtime. See also https://bbs.archlinux.org/viewtopic.php?pid=2084489#p2084489
Comment by nl6720 (nl6720) - Sunday, 19 March 2023, 22:04 GMT
That should be correct, but the C.UTF-8 locale does not have a collversion in the pg_collation table (`SELECT collname FROM pg_collation WHERE collversion IS NULL;`), so it'll never trigger the issue.
Comment by loqs (loqs) - Sunday, 19 March 2023, 22:18 GMT
Ah so it avoids the issue if there are no other locales installed on the system at the time initdb [1] is executed.
Edit:
Or the generated collations for other locales are removed after initdb created them assuming they are not used.

[1] https://github.com/postgres/postgres/blob/REL_15_2/src/bin/initdb/initdb.c#L1557

Loading...