Re: Block-level CRC checks

Поиск
Список
Период
Сортировка
От Aidan Van Dyk
Тема Re: Block-level CRC checks
Дата
Msg-id 20081117134120.GS31053@yugib.highrise.ca
обсуждение исходный текст
Ответ на Re: Block-level CRC checks  (Greg Stark <greg.stark@enterprisedb.com>)
Ответы Re: Block-level CRC checks  (Martijn van Oosterhout <kleptog@svana.org>)
Re: Block-level CRC checks  (Gregory Stark <stark@enterprisedb.com>)
Re: Block-level CRC checks  ("Matthew T. O'Connor" <matthew@zeut.net>)
Список pgsql-hackers
* Greg Stark <greg.stark@enterprisedb.com> [081117 03:54]:
> [sorry for top-posting - damn phone]
>
> I thought of saying that too but it doesn't really solve the problem.  
> Think of what happens if someone sets a hint bit on a dirty page.

If the page is dirty from a "real change", then it has a WAL backup block
record already, so the torn-page on disk is going to be fixed with the wal
replay ... *because* of the torn-page problem already being "solved" in PG.
You don't get the hint-bits back, but that's no different from the current
state.  But nobody's previously cared if hint-bits wern't set on WAL replay.

The tradeoff for CRC is:

1) Are hint-bits "worth saving"? (noting that with CRC the goal is the  ability of detecting blocks that aren't
*exactly*as we wrote them)
 
2) Are hint-bits "nice, but not worth IO" (noting that this case can be  mitigated to only pages which are hint-bit
*only*changed, not dirty with   already-wal-logged changes)
 

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

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

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Client certificate authentication
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Synchronous replication patch v2