On Tue, Sep 25, 2012 at 09:10:33AM -0400, Bruce Momjian wrote:
> > 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 canonicaliza
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,
于 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
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
于 2012/9/24 22:57, Bruce Momjian 写道:
On Mon, Sep 24, 2012 at 10:45:34PM +0800, Rural Hunter wrote:
If your operating system locale/encoding names changed after the initdb
of the old cluster, this would not be reflected in template0.
No. It's not changed. look at my system settings:
LANG=zh_CN.U
On Mon, Sep 24, 2012 at 11:04:32AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > 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. Did we change th
On Mon, Sep 24, 2012 at 10:45:34PM +0800, Rural Hunter wrote:
> >If your operating system locale/encoding names changed after the initdb
> >of the old cluster, this would not be reflected in template0.
> No. It's not changed. look at my system settings:
> LANG=zh_CN.UTF-8
> $ cat /var/lib/locales/s
On 9/24/12 10:13 AM, Tom Lane wrote:
> FWIW, what I found out last time I touched this code is that on many
> systems setlocale doesn't bother to return a canonicalized spelling;
> it just gives back the string you gave it. It might be worth doing
> what Peter suggests, just to be consistent with
On Mon, Sep 24, 2012 at 11:04:32AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > 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. Did we change th
On 9/24/12 11:04 AM, Tom Lane wrote:
> Bruce Momjian writes:
>> 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. Did we change the way we
>> canonicalize
Bruce Momjian writes:
> On Mon, Sep 24, 2012 at 11:22:22AM -0400, Peter Eisentraut wrote:
>> initdb has changed POSIX to C with glibc at least since 8.3. The code
>> you're quoting is just a refactoring, AFAICT.
> Frankly, I assumed the values assigned in pg_database for template0 were
> canonic
On Mon, Sep 24, 2012 at 11:22:22AM -0400, Peter Eisentraut wrote:
> On 9/24/12 11:04 AM, Tom Lane wrote:
> > Bruce Momjian writes:
> >> 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 i
On Mon, Sep 24, 2012 at 11:24:04AM -0400, Peter Eisentraut wrote:
> On 9/24/12 10:13 AM, Tom Lane wrote:
> > FWIW, what I found out last time I touched this code is that on many
> > systems setlocale doesn't bother to return a canonicalized spelling;
> > it just gives back the string you gave it.
Bruce Momjian writes:
> 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. Did we change the way we
> canonicalize the locale between 9.1 and 9.2?
IIRC, we
于 2012/9/24 22:26, Bruce Momjian 写道:
On Mon, Sep 24, 2012 at 09:59:02PM +0800, Rural Hunter wrote:
于 2012/9/24 20:55, Bruce Momjian 写道:
On Sun, Sep 23, 2012 at 06:46:33PM -0400, Peter Eisentraut wrote:
On Sun, 2012-09-23 at 22:20 +0800, Rural Hunter wrote:
Ah yes, seems I used a wrong paramet
Bruce Momjian writes:
> On Mon, Sep 24, 2012 at 10:13:45AM -0400, Tom Lane wrote:
>> FWIW, what I found out last time I touched this code is that on many
>> systems setlocale doesn't bother to return a canonicalized spelling;
>> it just gives back the string you gave it. It might be worth doing
>
On Mon, Sep 24, 2012 at 10:13:45AM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> >>> I can confirm that pg_upgrade does case-insensitive comparisons of
> >>> encoding/locale names:
>
> > Or we could just remove dashes from the name before comparisons.
>
> That would merely move the breakage s
On Mon, Sep 24, 2012 at 09:59:02PM +0800, Rural Hunter wrote:
> 于 2012/9/24 20:55, Bruce Momjian 写道:
> >On Sun, Sep 23, 2012 at 06:46:33PM -0400, Peter Eisentraut wrote:
> >>On Sun, 2012-09-23 at 22:20 +0800, Rural Hunter wrote:
> >>>Ah yes, seems I used a wrong parameter. The --locale='zh_CN.utf8'
Bruce Momjian writes:
>>> I can confirm that pg_upgrade does case-insensitive comparisons of
>>> encoding/locale names:
> Or we could just remove dashes from the name before comparisons.
That would merely move the breakage somewhere else. I think you are
already assuming far too much about the
于 2012/9/24 20:55, Bruce Momjian 写道:
On Sun, Sep 23, 2012 at 06:46:33PM -0400, Peter Eisentraut wrote:
On Sun, 2012-09-23 at 22:20 +0800, Rural Hunter wrote:
Ah yes, seems I used a wrong parameter. The --locale='zh_CN.utf8'
works. --locale='zh_CN.UTF8' also works. But still the question is,
sho
On Mon, Sep 24, 2012 at 09:06:04AM -0400, Peter Eisentraut wrote:
> On 9/24/12 8:55 AM, Bruce Momjian wrote:
> > I can confirm that pg_upgrade does case-insensitive comparisons of
> > encoding/locale names:
> >
> > static void
> > check_locale_and_encoding(ControlData *oldctrl,
> >
On 9/24/12 8:55 AM, Bruce Momjian wrote:
> I can confirm that pg_upgrade does case-insensitive comparisons of
> encoding/locale names:
>
> static void
> check_locale_and_encoding(ControlData *oldctrl,
> ControlData *newctrl)
> {
> /* Thes
On Sun, Sep 23, 2012 at 06:46:33PM -0400, Peter Eisentraut wrote:
> On Sun, 2012-09-23 at 22:20 +0800, Rural Hunter wrote:
> > Ah yes, seems I used a wrong parameter. The --locale='zh_CN.utf8'
> > works. --locale='zh_CN.UTF8' also works. But still the question is,
> > should the encoding name be
On Sun, 2012-09-23 at 22:20 +0800, Rural Hunter wrote:
> Ah yes, seems I used a wrong parameter. The --locale='zh_CN.utf8'
> works. --locale='zh_CN.UTF8' also works. But still the question is,
> should the encoding name be case sensitive?
PostgreSQL treats encoding names as case insensitive.
Bu
于2012年9月23日 20:33:48,Peter Eisentraut写到:
On Fri, 2012-09-21 at 17:16 +0800, Rural Hunter wrote:
If I run initdb with '-E zh_CN.utf8', it will tell me there
is no such charset in the system.
Because that is the name of a locale, not an encoding.
I found a workaround to run initdb
with '--lc
On Fri, 2012-09-21 at 17:16 +0800, Rural Hunter wrote:
> If I run initdb with '-E zh_CN.utf8', it will tell me there
> is no such charset in the system.
Because that is the name of a locale, not an encoding.
> I found a workaround to run initdb
> with '--lc-collate=zh_CN.utf8 --lc-ctype=zh_CN.
On Fri, Sep 21, 2012 at 05:16:46PM +0800, Rural Hunter wrote:
> >>I am thinking this query needs to be split apart into a UNION where the
> >>second part handles TOAST tables and looks at the schema of the _owner_
> >>of the TOAST table. Needs to be backpatched too.
> >OK, I am at a conference now
于 2012/9/19 7:22, Bruce Momjian 写道:
On Mon, Sep 17, 2012 at 05:07:23PM -0400, Bruce Momjian wrote:
# select * from pg_tables where tablename='sql_features';
schemaname | tablename | tableowner | tablespace |
hasindexes | hasrules | hastriggers
+--+
On Tue, Sep 18, 2012 at 07:22:39PM -0400, Bruce Momjian wrote:
> > Based on the fact that sql_features exists in the information_schema
> > schema, I don't think 'sql_features' table is actually being processed
> > by pg_upgrade, but I think its TOAST table, because it has a high oid,
> > is being
On Mon, Sep 17, 2012 at 05:07:23PM -0400, Bruce Momjian wrote:
> > # select * from pg_tables where tablename='sql_features';
> > schemaname | tablename | tableowner | tablespace |
> > hasindexes | hasrules | hastriggers
> > +--+++--
On Mon, Sep 17, 2012 at 01:03:37PM +0800, Rural Hunter wrote:
> >As you can see, we look at the existing TOAST usage and force the new
> >cluster to match. As I remember we replay the DROP COLUMN in binary
> >upgrade mode so the new cluster always matches the old cluster's TOAST
> >usage. I certa
于2012年9月17日 12:47:11,Tom Lane写到:
Bruce Momjian writes:
On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
Well, that's even stranger, because (1) information_schema.sql_features
ought to have a toast table in either version, and (2) neither pg_dump
nor pg_upgrade ought to be attempting
于2012年9月17日 12:32:36,Bruce Momjian写到:
On Sun, Sep 16, 2012 at 06:04:16PM -0400, Tom Lane wrote:
Bruce Momjian writes:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
I ran the pg_upgrade with the patch and found the problematic object
is a toast object.
OK, this is exactly wh
Bruce Momjian writes:
> On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
>> Well, that's even stranger, because (1) information_schema.sql_features
>> ought to have a toast table in either version, and (2) neither pg_dump
>> nor pg_upgrade ought to be attempting to dump or transfer that t
On Sun, Sep 16, 2012 at 09:48:58PM -0400, Tom Lane wrote:
> Rural Hunter writes:
> > # select oid, * from pg_class WHERE reltoastrelid = 16439148;
> >oid| relname| relnamespace | reltype | reloftype |
> > relowner | relam | relfilenode | reltablespace | relpages | reltuples |
> >
On Sun, Sep 16, 2012 at 06:04:16PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
> >> I ran the pg_upgrade with the patch and found the problematic object
> >> is a toast object.
>
> > OK, this is exactly what I wanted to see, and
Rural Hunter writes:
> äº2012å¹´9æ17æ¥ 9:48:58,Tom Laneåå°:
>> I wonder whether you dropped and recreated the information_schema in
>> the lifetime of this database? We have recommended doing that in the
>> past, IIRC. Could such a thing have confused pg_dump?
> No, I have never manually
于2012年9月17日 9:48:58,Tom Lane写到:
Rural Hunter writes:
# select oid, * from pg_class WHERE reltoastrelid = 16439148;
oid| relname| relnamespace | reltype | reloftype |
relowner | relam | relfilenode | reltablespace | relpages | reltuples |
reltoastrelid | reltoastidxid | relhasinde
Rural Hunter writes:
> # select oid, * from pg_class WHERE reltoastrelid = 16439148;
>oid| relname| relnamespace | reltype | reloftype |
> relowner | relam | relfilenode | reltablespace | relpages | reltuples |
> reltoastrelid | reltoastidxid | relhasindex | relisshared |
> relpe
于2012年9月17日 1:17:46,Bruce Momjian写到:
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
OK, I see many new ALTER TABLE commands, but nothing that would cause a
difference in relation count.
Attached is a patch that will return the OID of the old/new mismatched
entries. Please resear
Bruce Momjian writes:
> On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
>> I ran the pg_upgrade with the patch and found the problematic object
>> is a toast object.
> OK, this is exactly what I wanted to see, and it explains why pg_dump
> didn't show it. Can you find out what tabl
On Sun, Sep 16, 2012 at 12:38:37PM +0800, Rural Hunter wrote:
> >OK, I see many new ALTER TABLE commands, but nothing that would cause a
> >difference in relation count.
> >
> >Attached is a patch that will return the OID of the old/new mismatched
> >entries. Please research the pg_class objects o
42 matches
Mail list logo
