-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >> Keep in mind that if you have tables and/or databases that don't >> change frequently, you can dump those beforehand to minimize >> the final downtime. > That's true, I had thought about that also. I guess I would save the > contents of the biggest tables to flat files using the COPY command, > then delete the copied rows, before doing the dump. Is what what you > had in mind? No need to delete the copied rows: just use the handy -t and -T flags for pg_dump to include/exclude specific tables. You also don't need to save to a flat file first unless you need/want a separate backup. For large tables foo and bar, assuming 8.3 on port 5432 and 8.4 on port 5840, you could do: * pg_dump -t foo -t bar -p 5432 | psql -p 5840 -f - Then your final migration steps would be: * Stop the app * pg_dump -T foo -T bar -p 5432 | psql -p 5840 -f - * Turn fsync back on and change the port to 5432 for 8.4 * Stop the 8.3 database * Restart 8.4 * Start the app All off the top of my head, requires heavy testing by QA first, assumes foo and bar are not used, etc. /disclaimer - -- Greg Sabino Mullane greg@xxxxxxxxxxxx End Point Corporation http://www.endpoint.com/ PGP Key: 0x14964AC8 201004151050 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkvHKDkACgkQvJuQZxSWSsjasACgmepXTrkz/rsoHsm/qKWxsyB9 YlYAoJHHeyd768IJC5RqNn2aXPD/80fp =6yRN -----END PGP SIGNATURE----- -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
