Re: [GENERAL] trouble with pg_upgrade 9.0 -> 9.1

> 19.12.2012, 21:47, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> > "Kevin Grittner" <kgrittn(at)mail(dot)com> writes:
> >
> >>  Groshev Andrey wrote:
> >>    Mismatch of relation names: database "database", old rel public.lob.ВерсияВнешнегоДокумента$Документ_pkey, new rel public.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 oids
SELECT binary_upgrade.set_next_index_pg_class_oid('786665369'::pg_catalog.oid);

ALTER TABLE 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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +