Re: Block-level CRC checks - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Block-level CRC checks
Date
Msg-id 20081112140813.GB4535@alvh.no-ip.org
Whole thread Raw
In response to Re: Block-level CRC checks  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Block-level CRC checks  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Block-level CRC checks  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Martijn van Oosterhout wrote:

> If you're going to look at the line pointers anyway, couldn't you just
> do it in one pass, like:
> 
> n = 0
> next = &tuple[n].hintbits
> pos = 0
> while pos < BLOCK_SIZE:
>   if pos == next: 
>     CRC_ADD( block[pos] & mask )
>     n++
>     next = &tuple[n].hintbits  # If n == numtups, next = BLOCK_SIZE
>   else:
>     CRC_ADD( block[pos]
>   pos++

For this to work, we would have to create two (or more) versions of the
calculate checksum macro, one for heap pages and other for other pages.
I'm not sure how bad is that.  The bit that's worse is that we'd need to
have external knowledge of what kind of page we're talking about (i.e.
FlushBuffer would need to know whether a page is heap or another kind).

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.

The immediately useful information arising from your note is that I
noticed I'm calling a heap routine on non-heap pages, because of setting
PD_UNLOGGED_CHANGE for ItemId flags on index pages.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Distinct types
Next
From: Heikki Linnakangas
Date:
Subject: Window functions review