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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
