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

Re: Block-level CRC checks

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: pgsql(at)mohawksoft(dot)com
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Aidan Van Dyk" <aidan(at)highrise(dot)ca>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, "Hannu Krosing" <hannu(at)2ndquadrant(dot)com>, "Decibel!" <decibel(at)decibel(dot)org>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Pg Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Block-level CRC checks
Date: 2008-10-01 23:29:21
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
pgsql(at)mohawksoft(dot)com writes:

> If you are going to double buffer, one presumes that for some non-zero
> period of time, the block must be locked during which it is copied. You
> wouldn't want it changing "mid-copy" would you? How is this any less of a
> hit than just calculating the checksum?

a) You wouldn't have to keep the lock while doing the I/O. Once the CRC+copy
is done you can release the lock secure in the knowledge that nobody is going
to modify your buffered copy before the kernel can grab its copy.

b) You don't have to worry about hint bits being modified underneath you. As
long as the CRC+copy is carefully written to copy whole atomic-sized
words/bytes and only read the original once then it won't matter if it catches
the hint bit before or after it's set. The CRC will reflect the value buffered
and eventually written.

  Gregory Stark
  Ask me about EnterpriseDB's RemoteDBA services!

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-10-01 23:41:24
Subject: Re: Block-level CRC checks
Previous:From: Matthew T. O'ConnorDate: 2008-10-01 23:18:22
Subject: Re: September CommitFest Closed

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