Re: Enabling Checksums - Mailing list pgsql-hackers

On Mon, 2013-03-04 at 13:58 -0500, Greg Smith wrote:
> On 3/4/13 2:11 AM, Simon Riggs wrote:
> > It's crunch time. Do you and Jeff believe this patch should be
> > committed to Postgres core?
> 
> I want to see a GUC to allow turning this off, to avoid the problem I 
> saw where a non-critical header corruption problem can cause an entire 
> page to be unreadable.  A variation on that capable of turning this off 
> altogether, as Craig suggested, is a good idea too.

Based on your comments as well those of Dan and Craig, I am leaning
toward a GUC that causes a checksum failure to be ignored. It will still
emit the checksum failure warning, but proceed.

That will then fall through to the normal header checks we've always
had, and the same zero_damaged_pages option. So, to get past a really
corrupt page, you'd need to set ignore_checksum_failure and
zero_damaged_pages.

> I'll write up a long discussion of filesystem trends and why I think 
> this is more relevant than ever if that's the main objection now.  There 
> is no such thing as a stable release of btrfs, and no timetable for when 
> there will be one.  I could do some benchmarks of that but I didn't 
> think they were very relevant.  Who cares how fast something might run 
> when it may not work correctly?  btrfs might as well be /dev/null to me 
> right now--sure it's fast, but maybe the data won't be there at all. 
> How long has it taken the Linux kernel to reach the point it handles 
> write barriers and fsync correctly?  It does not give me a lot of 
> confidence that now is the time they'll suddenly start executing on 
> database filesystem mechanics perfectly.

I have a similar viewpoint here. It will take significant effort to come
up with anything, and I'm not sure how meaningful the numbers would be.
Even if btrfs is great, this feature is not mutually exclusive with
btrfs: * users might not have easy access to run the filesystem * they might not trust it * they might get poor
performancenumbers * postgres checksums might provide a good test of btrfs checksums, and
 
vice-versa, until both are stable

Additionally, I don't like the idea of depending so heavily on what
linux is doing. If there are performance problems that affect postgres,
will they fix them? Will they introduce new ones? Are there a zillion
tuneable options that a new user has to get right in order to run
postgres efficiently, and will poor settings mean a bunch of "postgres
is slow" blog posts?

Regards,Jeff Davis