On Wed, May 8, 2013 at 02:27:18PM -0400, Evan D. Hoffman wrote: > If you want to start the old cluster, you will need to remove > the ".old" suffix from /var/lib/pgsql/9.1/data/global/pg_control.old. > Because "link" mode was used, the old cluster cannot be safely > started once the new cluster has been started. > > Linking user relation files > /var/lib/pgsql/9.1/data/base/16406/3016054 > Mismatch of relation OID in database "dbname": old OID 2938685, new OID 299721 > Failure, exiting
[ Moved to hackers ] OK, that is odd. We preserve old/new OIDs, (not relfilenode, as someone suggested in this thread); FYI: * FYI, while pg_class.oid and pg_class.relfilenode are initially the same * in a cluster, but they can diverge due to CLUSTER, REINDEX, or VACUUM * FULL. The new cluster will have matching pg_class.oid and * pg_class.relfilenode values and be based on the old oid value. This can * cause the old and new pg_class.relfilenode values to differ. In summary, * old and new pg_class.oid and new pg_class.relfilenode will have the * same value, and old pg_class.relfilenode might differ. The problem reported is that pg_dump was not able to preserve the old/new oids between clusters. Can you get the answer for this query on the old cluster: SELECT relname from pg_class where oid = 2938685; and on the new cluster, assuming you used 'copy' mode so you can start the old/new clusters indepdendently: SELECT relname from pg_class where oid = 299721; I think we will find that there is something in pg_dump related to this table that isn't preserving the oids. -- 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