Re: Freeze avoidance of very large table.

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(at)momjian(dot)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 +