Re: 16-bit page checksums for 9.2

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: 16-bit page checksums for 9.2
Дата
Msg-id CAM-w4HOV41T6tXXS6n4o-GMW61jkxgo-8DQ-Px62Yy90COGgoA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On Sat, Dec 24, 2011 at 4:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> Checksums merely detect a problem, whereas FPWs correct a problem if
> it happens, but only in crash situations.
>
> So this does nothing to remove the need for FPWs, though checksum
> detection could be used for double write buffers also.

This is missing the point. If you have a torn page on a page that is
only dirty due to hint bits then the checksum will show a spurious
checksum failure. It will "detect" a problem that isn't there.

The problem is that there is no WAL indicating the hint bit change.
And if the torn page includes the new checksum but not the new hint
bit or vice versa it will be a checksum mismatch.

The strategy discussed in the past was moving all the hint bits to a
common area and skipping them in the checksum. No amount of double
writing or buffering or locking will avoid this problem.

-- 
greg


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

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Moving more work outside WALInsertLock
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: 16-bit page checksums for 9.2