Re: Freeze avoidance of very large table. - Mailing list pgsql-hackers

From andres@anarazel.de (Andres Freund)
Subject Re: Freeze avoidance of very large table.
Date
Msg-id 20151217072626.GK23112@awork2.anarazel.de
Whole thread Raw
In response to Re: Freeze avoidance of very large table.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 2015-12-17 16:22:24 +0900, Michael Paquier wrote:
> On Thu, Dec 17, 2015 at 4:10 PM, Andres Freund <andres@anarazel.de> wrote:
> > On 2015-12-17 15:56:35 +0900, Michael Paquier wrote:
> >> On Thu, Dec 17, 2015 at 3:44 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >> > 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.
> >>
> >> FWIW, I'm following this line and merging the vm file into a single
> >> unit looks like a ticking bomb.
> >
> > And what are those risks?
> 
> Incorrect vm file rewrite after a pg_upgrade run.

If we can't manage to rewrite a file, replacing a binary b1 with a b10,
then we shouldn't be working on a database. And if we screw up, recovery
i is an rm *_vm away. I can't imagine that this is going to be the
actually complicated part of this feature.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Peter Geoghegan
Date:
Subject: Re: Refactoring speculative insertion with unique indexes a little