Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1 - Mailing list pgsql-hackers

> 19.12.2012, 21:47, "Tom Lane" <tgl@sss.pgh.pa.us>:
> > "Kevin Grittner" <kgrittn@mail.com> writes:
> >
> >>  Groshev Andrey wrote:
> >>    Mismatch of relation names: database "database", old rel public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new
relpublic.plob.ВерсияВнешнегоДокумента$Документ
 
> >>  There is a limit on identifiers of 63 *bytes* (not characters)
> >>  after which the name is truncated. In UTF8 encoding, the underscore
> >>  would be in the 64th position.
> >
> > Hmm ... that is a really good point, except that you are not counting
> > the "lob." or "plob." part, which we previously saw is part of the
> > relation name not the schema name.  Counting that part, it's already
> > overlimit, which seems to be proof that Andrey isn't using UTF8 but
> > some single-byte encoding.
> >
> > Anyway, that would only explain the issue if pg_upgrade were somehow
> > changing the database encoding, which surely we'd have heard complaints
> > about already?  Or maybe this has something to do with pg_upgrade's
> > client-side encoding rather than the server encoding...
> >
> >                         regards, tom lane

> I'm initialize data dir with use ru_RU.UTF8, but this databse use CP1251, ie one byte per character.

Agreed.  This is a complicated report because the identifiers:

*  contain periods
*  are long
*  are in cyrillic
*  don't use utf8
*  are very similar

However, I just can't see how these could be causing the problem. 
Looking at the 9.1 pg_upgrade code, we already know that there are the
same number of relations in old and new clusters, so everything must be
being restored.  And there is a lob.* and a plob.* that exist.  The C
code is also saying that the pg_class.oid of the lob.* in the old
database is the same as the plob.* in the new database.  That question
is how is that happening.  

Can you email me privately the output of:
pg_dump --schema-only --binary-upgrade database

Thanks.  If you want to debug this yourself, check these lines in the
pg_dump output:
-- For binary upgrade, must preserve pg_class oidsSELECT
binary_upgrade.set_next_index_pg_class_oid('786665369'::pg_catalog.oid);ALTERTABLE ONLY
"lob.ВерсияВнешнегоДокумента$Документ"   ADD CONSTRAINT "plob.ВерсияВнешнегоДокумента$Документ" PRIMARY KEY ("@Файл",
"Страница");

See that 786665369?  That is the pg_class.oid of the plob in the old
cluster, and hopefully the new one.  Find where the lob*_pkey index is
created and get that oid.  Those should match the same names of the
pg_class.oid in the old and new clusters, but it seems the new plob* oid
is matching the lob oid in the old cluster.

Also, pg_upgrade sorts everything by oid, so it can't be that somehow
pg_upgrade isn't ordering things right, and because we already passed
the oid check, we already know they have the same oid, but different
names.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +