Re: Freeze avoidance of very large table.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Freeze avoidance of very large table.
Дата
Msg-id CA+TgmoZ8kV8ePYPNQgZHKFTB9ECkoWM6PdseuRF=66_vChwQoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Freeze avoidance of very large table.  (andres@anarazel.de (Andres Freund))
Список pgsql-hackers
On Thu, Dec 17, 2015 at 2:26 AM, Andres Freund <andres@anarazel.de> wrote:
> 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.

Yeah.  If that part of this feature isn't right, the chances that the
rest of the patch are robust enough to commit seem extremely low.
That is, as Andres says, not the hard part.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Remove array_nulls?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Remove array_nulls?