That's correct. Here's what substitutionlist_pkey looks like in the new
cluster. From this, it looks like it's actually correct (the oid for
substitutionlist_pkey is correct) but pg_upgrade thinks it's wrong and
dies. I'll look for the logs you requested and send them separately
db=# SELECT relname, relfilenode, relkind from pg_class where oid = 299749;
relname | relfilenode | relkind
----------------+-------------+---------
pg_toast_17304 | 299749 | t
(1 row)
db=# select oid, relname, relfilenode, pg_relation_filepath(oid), relkind
from pg_class where relname='substitutionlist_pkey';
oid | relname | relfilenode | pg_relation_filepath |
relkind
---------+-----------------------+-------------+----------------------+---------
2938685 | substitutionlist_pkey | 2938685 | base/16488/2938685 | i
(1 row)
db=# select version();
version
--------------------------------------------------------------------------------------------------------
------
PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.7
20120313 (Red Hat 4.4.7-3), 6
4-bit
(1 row)
db=#
On Thu, May 9, 2013 at 3:29 PM, Bruce Momjian <br...@momjian.us> wrote:
> On Thu, May 9, 2013 at 03:23:20PM -0400, Evan D. Hoffman wrote:
> > I just did the whole process over from the beginning. here's the full
> output:
> >
> > Copying user relation files
> > /var/lib/pgsql/9.1/data/base/16406/3016054
> > Mismatch of relation OID in database "db": old OID 2938685, new OID
> 299749
> > Failure, exiting
> >
> > real 16m17.924s
> > user 1m34.334s
> > sys 1m27.519s
> > Thu May 9 14:47:25 EDT 2013
> >
> > Here's the query of that OID:
> >
> > db=# SELECT relname, relfilenode, relkind from pg_class where oid =
> 299749;
> > relname | relfilenode | relkind
> > ----------------+-------------+---------
> > pg_toast_17304 | 299749 | t
> > (1 row)
> >
> > db=#
>
> OK, so the old oid matches 'substitutionlist_pkey' and the new oid
> matches 'pg_toast_17304'. Is that right? Does 'substitutionlist_pkey'
> exist in the new cluster at all? You need to see if 2938685 exists in
> the per-database dump file that should exist in the current directory,
> and show me the lines matching and the DDL command below that. You can
> email me the entire file privately if you want --- there is only DDL in
> there, no data (please verify if you are concerned).
>
> --
> Bruce Momjian <br...@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + It's impossible for everything to be true. +
>
