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

20.12.2012, 11:43, "Bruce Momjian" <bruce(at)momjian(dot)us>:
>>  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. +

Yes, was the last question. How to find out which version should stay?
And of course, I forgot to say a great big thank you!