From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Mark Woodward <pgsql(at)mohawksoft(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Upgrading a database dump/restore |
Date: | 2006-10-09 16:27:21 |
Message-ID: | 2980.1160411241@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> The hard part going to be making sure that even if
> the power fails halfway through an upgrade that your data will still be
> readable...
I think we had that problem solved too in principle: build the new
catalogs in a new $PGDATA directory alongside the old one, and hard-link
the old user table files into that directory as you go. Then pg_upgrade
never needs to change the old directory tree at all. This gets a bit
more complicated in the face of tablespaces but still seems doable.
(I suppose it wouldn't work in Windows for lack of hard links, but
anyone trying to run a terabyte database on Windows deserves to lose
anyway.)
The stuff that needed rethinking in the old pg_upgrade code, IIRC, had
to do with management of transaction IDs and old WAL log.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Woodward | 2006-10-09 16:30:13 | Re: Upgrading a database dump/restore |
Previous Message | Strong, David | 2006-10-09 16:21:22 | Re: Prepared Statement Question |