Re: Enabling Checksums - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Enabling Checksums
Date
Msg-id 50C90AA1.4030005@2ndQuadrant.com
Whole thread Raw
In response to Re: Enabling Checksums  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Enabling Checksums  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On 12/5/12 6:49 PM, Simon Riggs wrote:
> * Zeroing pages, making pages all 1s
> * Transposing pages
> * Moving chunks of data sideways in a block
> * Flipping bits randomly
> * Flipping data endianness
> * Destroying particular catalog tables or structures

I can take this on, as part of the QA around checksums working as 
expected.  The result would be a Python program; I don't have quite 
enough time to write this in C or re-learn Perl to do it right now.  But 
this won't be a lot of code.  If it's tossed one day as simply a 
prototype for something more permanent, I think it's still worth doing now.

The UI I'm thinking of for what I'm going to call pg_corrupt is a CLI 
that asks for:

-A relation name
-Corruption type (an entry from this list)
-How many blocks to touch

I'll just loop based on the count, randomly selecting a block each time 
and messing with it in that way.

The randomness seed should be printed as part of the output, so that 
it's possible re-create the damage exactly later.  If the server doesn't 
handle it correctly, we'll want to be able to replicate the condition it 
choked on exactly later, just based on the tool's log output.

Any other requests?

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Use gcc built-in atomic inc/dec in lock.c
Next
From: Andres Freund
Date:
Subject: Re: Logical decoding & exported base snapshot