Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING

Поиск
Список
Период
Сортировка
От Andrey M. Borodin
Тема Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING
Дата
Msg-id 82CBB5F5-F32A-4FA7-895A-9051F45F6894@yandex-team.ru
обсуждение исходный текст
Ответ на Re: Allow ERROR from heap_prepare_freeze_tuple to be downgraded to WARNING  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers

> 21 июля 2020 г., в 00:36, Alvaro Herrera <alvherre@2ndquadrant.com> написал(а):
>
>
>> FWIW we coped with this by actively monitoring this kind of corruption
>> with this amcheck patch [0]. One can observe this lost page updates
>> cheaply in indexes and act on first sight of corruption: identify
>> source of the buggy behaviour.
>
> Right.
>
> I wish we had some way to better protect against this kind of problems,
> but I don't have any ideas.  Some things can be protected against with
> checksums, but if you just lose a write, there's nothing to indicate
> that.  We don't have a per-page write counter, or a central repository
> of per-page LSNs or checksums, and it seems very expensive to maintain
> such things.

If we had data checksums in another fork we could flush them on checkpoint.
This checksums could protect from lost page update.
And it would be much easier to maintain these checksums for SLRUs.

Best regards, Andrey Borodin.


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

Предыдущее
От: "k.jamison@fujitsu.com"
Дата:
Сообщение: RE: Parallel Seq Scan vs kernel read ahead
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Parallel Seq Scan vs kernel read ahead