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

Re: Block-level CRC checks

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-30 15:22:57
Message-ID: 20081030152257.GD3857@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> 
> > Alvaro Herrera wrote:
> >
> >> The "other hint bits" are:
> >> 
> >> - LP_DEAD as used by the various callers of ItemIdMarkDead.
> >> - PD_PAGE_FULL
> >> - BTPageOpaque->btpo_flags and btpo_cycleid
> >> 
> >> All of them are changed with only SetBufferCommitInfoNeedsSave being
> >> called afterwards.
> >
> > I think we could get away with WAL-logging LP_DEAD via ItemIdMarkDead
> > similar to what is done to SetHintBits in the posted patch, and cope
> > with the rest by marking the page with the invalid checksum; they are
> > not so frequent anyway so the reliability loss is low.
> 
> If PD_PAGE_FULL is set and that causes the crc to be set to the invalid sum
> will we ever get another chance to set it?

I should have qualified that a bit more.  It's not setting PD_FULL
that's not logged, but clearing it (heap_prune_page, line 282).  It's
set in heap_update.

Hmm, oh I see another problem here -- the bit is not restored when
replayed heap_update's WAL record.  I'm now wondering what other bits
are set without much care about correctly restoring them during replay.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2008-10-30 15:27:07
Subject: Re: Block-level CRC checks
Previous:From: Jonah H. HarrisDate: 2008-10-30 15:22:18
Subject: Re: Block-level CRC checks

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