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

Re: Block-level CRC checks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-11-12 20:24:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Martijn van Oosterhout wrote:
> On Wed, Nov 12, 2008 at 11:08:13AM -0300, Alvaro Herrera wrote:

> > However, your idea suggests something else that we could do to improve
> > the patch: skip the ItemId->lp_flags during the CRC calculation.  This
> > would mean we wouldn't need to WAL-log those.  The problem with that is
> > that lp_flags are only 2 bits, so we would need to iterate zeroing them
> > and restore them after CRC_COMP() instead of simply skipping.
> Not sure why you're so intent on actually changing memory just so you can use
> COMP_CRC32, which is just a for loop around the COMP_CRC32_ONE I
> mentioned. Actually changing the memory probably means locking so why
> bother.

Well, that's one of the problems -- memory is being changed without
holding a lock.  The other problem is that of pages being changed, their
CRCs calculated, and then a crash occuring.  On recovery, the CRC is
restored but some of those changed bits are not.

The other thing that maybe you didn't notice is that lp_flags are 2
bits, not a full byte.  A byte-at-a-time CRC calculation is no help

Alvaro Herrera                      
The PostgreSQL Company - Command Prompt, Inc.

In response to


pgsql-hackers by date

Next:From: Gregory StarkDate: 2008-11-12 20:38:33
Subject: Re: Block-level CRC checks
Previous:From: Martijn van OosterhoutDate: 2008-11-12 20:16:09
Subject: Re: Block-level CRC checks

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