δΊ 2012/9/25 11:00, Bruce Momjian ει:
On Tue, Sep 25, 2012 at 08:41:19AM +0800, Rural Hunter wrote:
I think the problem is on the options when I installed pgsql(both
9.1 and 9.2)
Select the locale to be used by the new database cluster.
Locale
[1] [Default locale]
[2] C
[3] POSIX
[4] zh_CN.utf8
[5] zh_HK.utf8
[6] zh_SG.utf8
[7] zh_TW.utf8
Please choose an option [1] : 4
I chose 4 instead of 1. I guess the default locale(option 1) is with dash.
Well, if you run that query on template0 in the old and new cluster, you
will see something different in the two of them. Could you have used
default in one and a non-dash in the other.
Yes, that's true. The upgrade is fine with both fresh installs(9.1
and 9.2) with option above(without-dash). The problem only happens
when I inited the 9.2 db with default locale(I guess that one has
OK, that is good to know. I developed the attached C program that does
the setlocale canonical test. On Debian Squeeze, I could not see any
change: if I pass en_US.UTF-8, I get en_US.UTF-8 returned; if I pass
en_US.UTF8, I get en_US.UTF8 returned. Can anyone test this and find a
case where the local is canonicalized? Run it this way:
$ canonical
LC_COLLATE = 3
LC_CTYPE = 0
$ canonical 0 en_US.UTF8
en_US.UTF8
We are looking for cases where the second argument produces a
non-matching locale name as output.
It matches on my system(ubuntu 10.10 server):
$ ./canonical
LC_COLLATE = 3
LC_CTYPE = 0
$ ./canonical 0 zh_CN.UTF-8
zh_CN.UTF-8
$ ./canonical 0 zh_CN.UTF8
zh_CN.UTF8
$ ./canonical 0 zh_CN.utf8
zh_CN.utf8
$ ./canonical 0 zh_CN.utf-8
zh_CN.utf-8
I tested the checker with the patch:
$ /opt/PostgreSQL/9.2/bin/pg_upgrade -b /opt/PostgreSQL/9.1/bin -B
/opt/PostgreSQL/9.2/bin -d /raid/pgsql -D /raid/pg92data -c
Performing Consistency Checks
-----------------------------
Checking current, bin, and data directories ok
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
lc_collate cluster values do not match: old "zh_CN.utf8", new "zh_CN.UTF-8"
Failure, exiting
zh_CN.utf8 is provided by the installer and zh_CN.UTF-8 is my system
default.
I have also attached a patch that reports the mismatching locale or
encoding names --- this should at least help with debugging and show
that a dash is the problem.
the dash). Just wondering why pg installer provides options without
dash.
No idea.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
