Message-ID: <50613193.4010204@gmail.com>
Date: Tue, 25 Sep 2012 12:22:43 +0800
From: Rural Hunter <ruralhunter@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1;
	rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Bruce Momjian <bruce@momjian.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed
References: <505C307E.20501@gmail.com>
	<1348403628.18490.1.camel@vanquo.pezone.net>
	<505F1A98.9090901@gmail.com>
	<1348440393.18490.2.camel@vanquo.pezone.net>
	<20120924125500.GA21242@momjian.us> <50606726.3050802@gmail.com>
	<20120924142659.GC21242@momjian.us> <5060720E.1080903@gmail.com>
	<20120924145731.GE21242@momjian.us>
	<5060FDAF.8020407@gmail.com> <20120925030017.GA4250@momjian.us>
In-Reply-To: <20120925030017.GA4250@momjian.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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