Re: [ADMIN] pg_upgrade from 9.1.3 to 9.2 failed

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

In response to

Responses

Browse pgsql-admin by date

  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

Browse pgsql-hackers by date

  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