On Thu, Oct 2, 2008 at 12:51 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
>> > But I thought you didn't really care about hint-bit updates, even in the
>> > current strategy... but I'm fully ignorant about the code, sorry...
>>
>> The current implementation does not take it into account.
>
> So if PG currently doesn't care about the hit-bits being updated, during
> the write, then why should introducing a double-buffer introduce the a
> torn-page problem Tom mentions?  I admit, I'm fishing for information
> from those in the know, because I haven't been looking at the code long
> enough (or all of it enough) to to know all the ins-and-outs...

PG doesn't care because during hint-bits aren't logged and during
normal WAL replay, the old page will be pulled from the WAL.  I
believe what Tom is referring to is that the buffer PG sends to
write() can still be modified by way of SetHintBits between the time
smgrwrite is called and the time the actual write takes place, which
is why we can't rely on a checksum of the buffer pointer passed to
smgrwrite and friends.

If we're double-buffering the write, I don't see where we could be
introducing a torn-page, as we'd actually be writing a copied version
of the buffer.  Will look into this.

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

In response to

• Re: Block-level CRC checks at 2008-10-02 16:51:01 from Aidan Van Dyk

Responses

• Re: Block-level CRC checks at 2008-10-02 17:07:31 from Bruce Momjian

pgsql-hackers by date

Next:	From: Bruce Momjian	Date: 2008-10-02 17:07:31
	Subject: Re: Block-level CRC checks
Previous:	From: Aidan Van Dyk	Date: 2008-10-02 16:51:01
	Subject: Re: Block-level CRC checks