On Thu, 2010-02-11 at 11:27 -0500, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > You still have to perform a backup of the database prior to upgrade and > > that also must scan the whole database, so the overall time to upgrade > > will still vary according to database size. So I don't see any overall > > benefit, just risk, and I cited a similar situation where that risk has > > already materialized into damage for a user in at least one case. > > You cited no such case; you merely hypothesized that it could happen.
Apologies for not providing more details. There was a serious problem in an 8.4.1 database just before Christmas. Mostly off-list but a few community members knew of it. The db had been upgraded from 8.4.0, where some data loss issues existed and the corruption persisted even in a release where it could never have been created. > As for the alleged risks involved, keeping the tqual support for MOVED > bits cannot create any data-loss risks that haven't existed right along > in every previous release. But depending on MOVED bits to be reliably > gone after a pg_upgrade would introduce a very obvious data loss risk > that wasn't there before, namely that pg_upgrade misses one. Avoiding a scan before running pg_upgrade is just a performance optimisation. I don't think we should be optimising an upgrade in this way, especially since sane people do database backups before upgrade anyway. The optimisation is misplaced. The fact that we are actively planning to have code in the server that only gets executed if pg_upgrade screws up scares the hell out of me. If someone else suggested it you'd give them both barrels. We should be ensuring pg_upgrade works, not giving it leeway to miss a few things but work quickly. I think pg_upgrade should be investing time in a utility which pre-scans the database to check it is safely upgradeable, not have the server support an external utility that has unsafe usage procedures. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers