Re: New CRC algorithm: Slicing by 8

["Simon Riggs" <simon(at)2ndquadrant(dot)com>]

On Tue, 2006-10-24 at 14:07 -0400, Tom Lane wrote:
> "Gregory Maxwell" <gmaxwell(at)gmail(dot)com> writes:
> > I'm not aware of any other system which can guaranteed the atomicity
> > of 8k writes.
> 
> The reasoning for supporting full_page_writes = off is that if you have
> a stable kernel and suitable backup power, battery backed write cache,
> etc, your risk of a partially completed write() may be low enough to
> be acceptable.  Obviously there are no 100.00% guarantees, but that's
> what you keep backups for ...
> 
> Simon is essentially arguing that if we are willing to assume no
> incomplete write() we may as well assume it for WAL too.  This seems
> to me to be raising the risk significantly, but I admit that I can't
> put my finger on why exactly.

I agree about the significant additional risk, hence the additional
parameter.

I'll do some internal testing to see what the risk-reward is. If that
seems worthwhile, then I'll post the patch for general testing/comment. 

(Incidentally, having GUCs that depend on other GUCs is bad news since
they are set alphabetically. I'd want to only allow wal_checksum=off iff
full_page_writes=off, which will work, but only because W comes after F
and for no other reason. Generic solution for dependent GUCs would be
great...)

> One point not directly related to crash safety is whether CRC checking
> isn't still going to be a good idea when PITR is enabled.  Archived WAL
> files are going to have been through a great deal more transferring than
> ones merely being used to recover from a crash.

Agreed. Both disks and tapes/other mechanisms must be known CRC-safe
before this idea would be worth using in production. Many enterprises do
already think they have bomb-proof kit, so we may as well support them
in that belief. 

-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com