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: "Aidan Van Dyk" <aidan(at)highrise(dot)ca>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 16:59:45
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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

In response to


pgsql-hackers by date

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

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