Skip site navigation (1) Skip section navigation (2)

Re: Block-level CRC checks

From: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Brian Hurt" <bhurt(at)janestcapital(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-02 15:27:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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
2. Doublebuffer the write
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

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-10-02 15:28:13
Subject: Re: Transactions within a function body
Previous:From: Reg Me PleaseDate: 2008-10-02 15:18:59
Subject: Re: Transactions within a function body

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group