Re: Block-level CRC checks - Mailing list pgsql-hackers

From Aidan Van Dyk
Subject Re: Block-level CRC checks
Date
Msg-id 20081117204041.GW31053@yugib.highrise.ca
Whole thread Raw
In response to Re: Block-level CRC checks  ("Matthew T. O'Connor" <matthew@zeut.net>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: patch to fix client only builds
Next
From: Alvaro Herrera
Date:
Subject: toast by chunk-end (was Re: PG_PAGE_LAYOUT_VERSION 5 - time for change)