Desciption of the issue is given at link. It seems that it is a PostgreSQL bug only. To resolve this issue, there seems to be only a single workaround, which is to create a list of locale (map) with key as <Language>_<Country>.<CodePage>and value as <Language>, <Country>.
For example:
English_United States.1252 = English, United States
...
Since value of parameter --locale is accepted in the format of <Language>, <Country>whereas output of command SHOW LC_COLLATE is in the format of <Language>_<Country>.<CodePage>. So, during an ugrade I will get the value of lc_collate cmd and get the corresponding value from the list and provide it during PostgreSQL 9.5 installation.
How do I convert <Language>_<Country>.<CodePage> to appropriate format for successful installation ?
Related
As this might have something to do with AWS Lightsail, I've cross posted this question on AWS - Click Here
I'm trying to create a template database using
CREATE DATABASE __edgedbtpl__ OWNER='edgedb' IS_TEMPLATE = TRUE TEMPLATE='template0' ENCODING='UTF8' LC_COLLATE='C' LC_CTYPE='C.UTF-8';
But this fails and gives me the error
ERROR: invalid locale name: "C.UTF-8"
I checked if the PostgreSQL server supports the C.UTF-8 locale, using
SELECT collname FROM pg_collation WHERE lower(replace(collname, '-', '')) = 'c.utf8' LIMIT 1;
which gives me the response
collname
----------
C.utf8
(1 row)
Question
How are the collnames in pg_collation different from SHOW LC_CTYPE and SHOW LC_COLLATE?
SHOW LC_COLLATE and SHOW LC_TYPE responded with en_US.UTF-8 and not C.UTF-8. So how should I identify if a certain locale is supported?
Collation names are identifiers, not string literals in PostgreSQL. Use double quotes instead of single quotes. Also, case and spelling matter, so use "C.utf8".
After an upgrade from Ubuntu Server 14.04 to 16.04 I had to also upgrade my Postgres clusters from 9.3 to 9.5. The normal way to do that is to first drop the (empty) 9.5 cluster that the upgrade created:
# pg_dropcluster 9.5 main
and then to upgrade the old 9.3 cluster to 9.5:
# pg_upgradecluster 9.3 main
This however results in an error:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US.UTF-8",
LC_ALL = (unset),
LC_PAPER = "nl_NL.UTF-8",
LC_ADDRESS = "nl_NL.UTF-8",
LC_MONETARY = "nl_NL.UTF-8",
LC_NUMERIC = "nl_NL.UTF-8",
LC_TELEPHONE = "nl_NL.UTF-8",
LC_IDENTIFICATION = "nl_NL.UTF-8",
LC_MEASUREMENT = "nl_NL.UTF-8",
LC_TIME = "nl_NL.UTF-8",
LC_NAME = "nl_NL.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Error: The locale requested by the environment is invalid.
Error: Could not create target cluster
This means I could not upgrade to Postgres 9.5.
I checked all locale settings:
the en_US.UTF-8 locale exists and is properly generated as checked with locale -a (it shows en_US.utf8 in its list)
The file /etc/environment contains LC_ALL=en_US.UTF-8 and LANG=en_US.UTF-8
/etc/default/locale contains the same setting for LANG, LANGUAGE and LC_ALL
I can start Perl without any issue using "perl -e exit"
The error message is generated from the pg_createcluster script which is called from pg_updatecluster. But running pg_createcluster from the command line works just fine, without any issue.
Workaround for the issue:
I used the following workaround to at least get the conversion to work. I edited the /usr/bin/pg_upgradecluster script, as follows:
Find the code where it calls pg_createcluster by looking for the comment "create new cluster"
That code consists of a series of "push" statements, ending in the suspicious line:
delete $ENV{'LC_ALL'}
Notice that this LC_ALL is exactly the variable that is unset in the error message.
Comment out that delete comment by adding a '#' before it, then save.
This at least circumvents this problem and lets you run the upgrade.
My question: is this a bug in the pg_upgradecluster script, or is something else awry on my system?
had the same problem on an ubuntu 16.04 server. what helped in my case was to generate all the locales that appear in your listing of $ locale:
$ sudo locale-gen "en_US.UTF-8"
$ sudo locale-gen "nl_NL.UTF-8"
good luck!
In my case, it was complaining about
Error: The locale requested by the environment is invalid:
LANG: en_GB
LANGUAGE: en_GB:en
So I unset LANG and unset LANGUAGE and it worked.
For me, I have followed many suggestions and still didn't work.
The script mentioned
LC_TIME=en_UK but it's totally unrelated so I ignored it at first.
Turns out this was the problem and doing "unset LC_TIME" was all I needed.
Posting here in case it happened to someone else.
My quick way to disable that message: (macOS 12 Monterey M1)
Open Terminal -> Preferences -> Advanced tab -> uncheck to Set locale environment variables on startup
Just came across this in fresh Ubuntu + PostgresQL install, after all those years.. either way, the solution is:
apt-get install locales
I try to create a collation on a new database(firebird3.0.1 on windows. I follows the steps:
create database 'c:\tmp\ebizmis.fdb' user 'SYSDBA' password '123456' default character set utf8 collation unicode;
connect 'c:\tmp\ebizmis.fdb' user 'SYSDBA' password '123456';
create collation py for utf8 from UNICODE case insensitive 'LOCALE=zh';
in this step, prompting error:
Statement failed, SQLSTATE = HY000
unsuccessful metadata update
-CREATE COLLATION PY failed
-Invalid collation attributes
But on CentOS it is successfull on firebird 3.0.1.
When I change the uppercase LOCALE to lowercase:
create collation py for utf8 from UNICODE case insensitive 'locale=zh';
then it can be excuted on windows, but do not work for sorting the characters in chinese pinyin order.
I cannot build Firebird 3.0.1 under windows, but I can build 2.5.6. So I debug under 2.5.6. I found there is no bug in Firebird. The cause of the problem is that I haven't include zh locale in the icu. So I download the data from icu web site and replace the file in 3.0.1. It works!
I am using UTF8 as encoding for my Postgres 8.4.11 database:
CREATE DATABASE test
WITH OWNER = postgres
ENCODING = 'UTF8'
TABLESPACE = mydata
LC_COLLATE = 'de_DE.UTF-8'
LC_CTYPE = 'de_DE.UTF-8'
CONNECTION LIMIT = -1;
ALTER DATABASE test SET default_tablespace='mydata';
ALTER DATABASE test SET temp_tablespaces=mydata;
And the output of \l
test | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
When I try to insert a German character:
create table x(a text);
insert into x values('ä,ß,ö');
ERROR: invalid byte sequence for encoding "UTF8": 0xe42cdf
HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by "client_encoding".
I am using puTTY to connect. Any idea?
The key element is the client_encoding - the encoding the server expects from your client. It has to match what is actually sent. What do you get for show client_encoding? Is it UNICODE?
Read more in the chapter Automatic Character Set Conversion Between Server and Client of the manual.
If you are using psql as client, you can set client_encoding with \encoding. Check the encoding your local system users (on Linux type locale in the shell) and set a matching client_encoding in psql. You can avoid such complications if you use the same locale on your system as you use as encoding for your PostgreSQL server.
If you use puTTY (on Windows), make sure to set its "Translation" accordingly. Have a look at Settings: Window - Translation. Must match client_encoding. You can right-click in a running session and chose Change Settings. You can also save these settings with your saved sessions.
Could anybody give an insight on the locale and numeric types behaviour in PostgreSQL? We work with Italian locale. That is comma separation for decimal part. Setting in postgresql.conf
# These settings are initialized by initdb, but they can be changed.
lc_messages = 'it_IT.UTF-8' # locale for system error message
# strings
lc_monetary = 'it_IT.UTF-8' # locale for monetary formatting
lc_numeric = 'it_IT.UTF-8' # locale for number formatting
lc_time = 'it_IT.UTF-8' # locale for time formatting
.. does nothing! It behaves in a quite appropriate way with dates and so, BUT the numeric type remains DOT separated for decimal part.
root#server:~# uname -a
Linux server 2.6.32-36-generic-pae #79-Ubuntu SMP Tue Nov 8 23:25:26 UTC 2011 i686 GNU/Linux
root#server:~# dpkg -l | grep postgresql
ii postgresql-8.4 8.4.9-0ubuntu0.10.04 object-relational SQL database, version 8.4
ii postgresql-client 8.4.9-0ubuntu0.10.04 front-end programs for PostgreSQL (supported)
EDIT
Having problem with implementation of locale in different scopes: db, server script, os and client side. Decided to avoid any locale formatting and use en_EN locale. The locale formatting will be applied only at the moment of output and so.
I quote the manual:
lc_numeric (string)
Sets the locale to use for formatting numbers, for example with the to_char family of functions.
Concerns these type formatting functions. You should be able to reproduce the following demo:
SHOW lc_numeric;
de_AT.UTF-8
SELECT to_number('13,4','999D99')
13.4
SELECT to_char(13.4,'FM999D99')
13,4
SET lc_numeric = 'C';
SELECT to_number('13,4','999D99')
134
SELECT to_char(13.4,'FM999D99')
13.4
RESET lc_numeric;
Template patterns in the manual.
The format of numbers in SQL expressions does not change with locale settings. That would be madness.
On a different note: you are aware that you have to (at least) reload the server after changing postgresql.conf.
pg_ctl reload