From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Rural Hunter <ruralhunter(at)gmail(dot)com> |
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 13:10:33 |
Message-ID: | 20120925131033.GB4250@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
On Tue, Sep 25, 2012 at 12:22:43PM +0800, Rural Hunter wrote:
> >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.
OK, this tells us that the canonicalization code used in initdb is not
going to help us in pg_upgrade, at least not on your system, and not on
mine.
I think we should apply the patch that fixes the TOAST problem with
information_schema, and the patch that outputs the old/new values for
easier debugging. Other than that, I don't know what else we can do
except to ignore dashes when comparing locale names, which I am told is
unacceptable.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2012-09-25 15:57:36 | Re: CPU causes 100% load in user space when ntp client runs and postgresql is under heavy load |
Previous 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 |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-09-25 13:15:43 | Re: DROP INDEX CONCURRENTLY is not really concurrency safe & leaves around undroppable indexes |
Previous Message | Heikki Linnakangas | 2012-09-25 12:58:49 | Re: Switching timeline over streaming replication |