Re: [HACKERS] pg_upgrade may be mortally wounded

> 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