Re: Block-level CRC checks
| От | Matthew T. O'Connor |
|---|---|
| Тема | Re: Block-level CRC checks |
| Дата | |
| Msg-id | 4921CDD8.8090204@zeut.net обсуждение исходный текст |
| Ответ на | Re: Block-level CRC checks (Aidan Van Dyk <aidan@highrise.ca>) |
| Ответы |
Re: Block-level CRC checks
|
| Список | pgsql-hackers |
Aidan Van Dyk wrote: > * Greg Stark <greg.stark@enterprisedb.com> [081117 03:54]: >> 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. What if all changes to a page (even hit bits) are WAL logged when running with Block-level CRC checks enables, does that make things easier? I'm sure it would result in some performance loss, but anyone enabling Block Level CRCs is already trading some performance for safety. Thoughts?
В списке pgsql-hackers по дате отправления: