Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От andres@anarazel.de (Andres Freund)
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id 20151217072626.GK23112@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (Michael Paquier <michael.paquier@gmail.com>)
Ответы Re: Freeze avoidance of very large table.  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Freeze avoidance of very large table.
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Refactoring speculative insertion with unique indexes a little