On Thu, 2010-02-11 at 11:27 -0500, Tom Lane wrote:
> Simon Riggs <simon@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