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

From Jonah H. Harris
Subject Re: Block-level CRC checks
Date
Msg-id 36e682920810020827x659e907fn32f5b1bb7053c6ff@mail.gmail.com
Whole thread Raw
In response to Re: Block-level CRC checks  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Responses Re: Block-level CRC checks
List pgsql-hackers
So, it comes down to two possible designs, each with its own set of challenges.

Just to see where to go from here... I want to make sure the options
I've seen in this thread are laid out clearly:

1. Hold an exclusive lock on the buffer during the call to smgrwrite
OR
2. Doublebuffer the write
OR
3. Do some crufty magic to ignore hint-bit updates

Because option 3 not only complicates the entire thing, but also makes
corruption more difficult to detect, I don't consider it viable.  Can
anyone provide a reason that makes this option viable?

Option 1 will prevent hint-bit updates during write, which means we
can checksum the buffer and not worry about it.  Also, is only the
buffer content lock required?  This could potentially slow down
concurrent transactions reading the block and/or writing hint bits.

Option #2 consists of copying the block to a temporary buffer,
checksumming it, and pushing the checksummed block down to write() (at
smgr/md/fd depending on where we want to perform the checksum).

From my perspective, I prefer #2 and performing it at the sgmr layer,
but I am open to suggestions.  Tom, what are your thoughts?  #1 isn't
very difficult, but I can see it potentially causing a number of
side-problems and it would require a fair amount of testing.

-- 
Jonah H. Harris, Senior DBA
myYearbook.com


pgsql-hackers by date:

Previous
From: "Jonah H. Harris"
Date:
Subject: Re: Block-level CRC checks
Next
From: "Gurjeet Singh"
Date:
Subject: Re: [GENERAL] Transactions within a function body