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 Lane||Date: 2008-10-02 15:28:13|
|Subject: Re: Transactions within a function body |
|Previous:||From: Reg Me Please||Date: 2008-10-02 15:18:59|
|Subject: Re: Transactions within a function body|