> I re-enabled pg_upgrade this afternoon, thinking that it would be easier
> to use than dump/initdb/reload for coping with the pg_statistic change
> I'm about to commit. However, testing shows that it doesn't really
> work. The "upgraded" database behaves very strangely --- vacuum tends
> to fail, and I have seen duplicate listings for attributes of a relation
> in psql's \d listing, broken links between a relation and its indices,
> and other problems.
>
> I think the problem is that pg_upgrade no longer works in the presence
> of MVCC. In particular, forcibly moving the old database's pg_log into
> the new is probably a bad idea when there is no similarity between the
> sets of committed transaction numbers. I suspect the reason for the
> strange behaviors I've seen is that after the pg_log copy, the system no
> longer believes that all of the rows in the new database's system tables
> have been committed.
>
> Is it possible to make pg_upgrade work again, perhaps by requiring a
> vacuum on the old and/or new databases just before the move happens?
> Or must we consign pg_upgrade to the dustbin of history?
I am unsure how MVCC would affect this. I will say that pg_upgrade does
not work when the underlying table structure changes, though I don't
think we have changed any of that. Strange.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026