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

On Wed, Dec 19, 2012 at 12:56:05PM -0500, Kevin Grittner wrote:
> 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.

OK, Kevin is certainly pointing out a bug in the pg_upgrade code, though
I am unclear how it would exhibit the mismatch error reported.

pg_upgrade uses NAMEDATALEN for database, schema, and relation name
storage lengths. While NAMEDATALEN works fine in the backend, it is
possible that a frontend client, like pg_upgrade, could retrieve a name
in the client encoding whose length exceeds NAMEDATALEN if the client
encoding did not match the database encoding (or is it the cluster
encoding for system tables). This would cause truncation of these
values. The truncation would not cause crashes, but might cause
failures by not being able to connect to overly-long database names, and
it weakens the checking of relation/schema names --- the same check that
is reported above.

(I believe initdb.c also erroneously uses NAMEDATALEN.)

For this to be the cause of the users report, there would have to be
different truncation behavior for old and new clusters when you restore
the dump. Did we change how this somehow between 9.0 and 9.1?

In summary, we are getting closer to a fix, but we are not there yet. I
can supply a patch that removes the use of NAMEDATALEN and you can test
that, but again, I don't see how that can cause this.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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