From: | Rural Hunter <ruralhunter(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed |
Date: | 2012-09-25 04:22:43 |
Message-ID: | 50613193.4010204@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin 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.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Brouwer | 2012-09-25 12:58:31 | Re: CPU causes 100% load in user space when ntp client runs and postgresql is under heavy load |
Previous Message | Bruce Momjian | 2012-09-25 03:00:17 | Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed |
From | Date | Subject | |
---|---|---|---|
Next Message | Dan Scott | 2012-09-25 04:23:45 | Re: plpgsql gram.y make rule |
Previous Message | Daniel Farina | 2012-09-25 04:18:36 | Re: Oid registry |