Re: pg_upgrade from 9.1.3 to 9.2 failed
| От | Bruce Momjian |
|---|---|
| Тема | Re: pg_upgrade from 9.1.3 to 9.2 failed |
| Дата | |
| Msg-id | 20120915180603.GA20907@momjian.us обсуждение исходный текст |
| Ответ на | Re: pg_upgrade from 9.1.3 to 9.2 failed (Rural Hunter <ruralhunter@gmail.com>) |
| Ответы |
Re: pg_upgrade from 9.1.3 to 9.2 failed
|
| Список | pgsql-admin |
On Sat, Sep 15, 2012 at 11:40:06AM +0800, Rural Hunter wrote: > >>>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. > > > diff attached. OK, I see many new ALTER TABLE commands, but nothing that would cause a difference in relation count. Attached is a patch that will return the OID of the old/new mismatched entries. Please research the pg_class objects on the old/new clusters that have the mismatch and let me know. It might be something that isn't in the old cluster, or not in the new cluster. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-admin по дате отправления: