20.12.2012, 11:43, "Bruce Momjian" <br...@momjian.us>:
>> 19.12.2012, 21:47, "Tom Lane" <t...@sss.pgh.pa.us>:
>>> "Kevin Grittner" <kgri...@mail.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 <br...@momjian.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!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
