Received: from magus.postgresql.org ([87.238.57.229]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TCanP-0001Md-BJ for pgsql-admin@postgresql.org; Fri, 14 Sep 2012 18:39:19 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TCanM-00033c-Pl for pgsql-admin@postgresql.org; Fri, 14 Sep 2012 18:39:18 +0000 Received: from bruce by momjian.us with local (Exim 4.72) (envelope-from ) id 1TCanL-0002EY-8q; Fri, 14 Sep 2012 14:39:15 -0400 Date: Fri, 14 Sep 2012 14:39:15 -0400 From: Bruce Momjian To: Rural Hunter Cc: pgsql-admin@postgresql.org Subject: Re: pg_upgrade from 9.1.3 to 9.2 failed Message-ID: <20120914183915.GA5933@momjian.us> References: <5052C402.8020003@gmail.com> <20120914142616.GA11265@momjian.us> <50535302.8080000@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50535302.8080000@gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Pg-Spam-Score: -2.4 (--) X-Archive-Number: 201209/85 X-Sequence-Number: 40026 On Fri, Sep 14, 2012 at 11:53:38PM +0800, Rural Hunter wrote: > >>Performing Upgrade > >>------------------ > >>Analyzing all rows in the new cluster ok > >>Freezing all rows on the new cluster ok > >>Deleting files from new pg_clog ok > >>Copying old pg_clog to new server ok > >>Setting next transaction ID for new cluster ok > >>Resetting WAL archives ok > >>Setting frozenxid counters in new cluster ok > >>Creating databases in the new cluster ok > >>Adding support functions to new cluster ok > >>Restoring database schema to new cluster ok > >>Removing support functions from new cluster ok > >>Copying user relation files > >> /raid/pgsql/base/6087920/6088238 > >>old and new databases "testdb" have a different number of relations > >>Failure, exiting > > > >That is an odd failure. That check was added in PG 9.1 and this is the > >first time I am seeing this failure. > > > >The check is to make sure that once we have created all the user schema > >details in the new cluster, that there are the same number of objects in > >the new and old databases. > > > >Obviously there are a different number in your case here, but I don't > >know why those would be different, and in fact, because we have never > >hit this, there isn't even any debug output that shows the source of the > >difference. > > > >If I send you a patch can you compile it and send back the debug output > >it produces? > > > > Yes sure, I will try to compile and retest with it. Actually, I have a simpler idea. At the point where it fails, you can run pg_dump --schema-only on the testdb database in the old and new cluster and then diff those output files and email the result to us; it should show the mismatch. I am not sure if the dumps will output the objects in the same order, it might. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +