On Thu, Dec 17, 2015 at 06:44:46AM +0000, Simon Riggs wrote:
> >> Thank you for having a look.
> >
> > I would not bother mentioning this detail in the pg_upgrade manual page:
> >
> > + Since the format of visibility map has been changed in version 9.6,
> > + <application>pg_upgrade</> creates and rewrite new <literal>'_vm'</
> literal>
> > + file even if upgrading from 9.5 or before to 9.6 or later with link
> mode (-k).
>
> Really? I know we don't always document things like this, but it
> seems like a good idea to me that we do so.
>
>
> Agreed.
>
> For me, rewriting the visibility map is a new data loss bug waiting to happen.
> I am worried that the group is not taking seriously the potential for
> catastrophe here. I think we can do it, but I think it needs these things
>
> * Clear notice that it is happening unconditionally and unavoidably
> * Log files showing it has happened, action by action
> * Very clear mechanism for resolving an incomplete or interrupted upgrade
> process. Which VMs got upgraded? Which didn't?
> * Ability to undo an upgrade attempt, somehow, ideally automatically by default
> * Ability to restart a failed upgrade attempt without doing a "double upgrade",
> i.e. ensure transformation is immutable
Have you forgotten how pg_upgrade works? This new vm file is only
created on the new cluster, which is not usable if pg_upgrade doesn't
complete successfully. pg_upgrade never modifies the old cluster.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Roman grave inscription +
