Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed - Mailing list pgsql-hackers

于 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.
>