Re: Block-level CRC checks
От | Aidan Van Dyk |
---|---|
Тема | Re: Block-level CRC checks |
Дата | |
Msg-id | 20081117204041.GW31053@yugib.highrise.ca обсуждение исходный текст |
Ответ на | Re: Block-level CRC checks ("Matthew T. O'Connor" <matthew@zeut.net>) |
Список | pgsql-hackers |
* Matthew T. O'Connor <matthew@zeut.net> [081117 15:19]: > 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? *I'ld* be more than happy for that trade-off, because: 1) I run PostgreSQL on old, crappy hardware 2) I run small databases 3) I've never had a situation where PG was already to slow 4) I'ld like to know when I really *should* dump old hardware... But I'm not going to loose money if my DB is down either, so I'ld hardly consider myself one to cater to ;-) -- Aidan Van Dyk Create like a god, aidan@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
В списке pgsql-hackers по дате отправления: