From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | pg_upgrade may be mortally wounded |
Date: | 1999-07-31 22:18:00 |
Message-ID: | 24009.933459480@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Hub.Org News Admin | 1999-07-31 23:01:56 | |
Previous Message | Roberth Andersson | 1999-07-31 19:22:23 | Re: [HACKERS] IPC Memory problem with Postmaster on BSDi 4.x |