Re: New CRC algorithm: Slicing by 8 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New CRC algorithm: Slicing by 8
Date
Msg-id 21857.1161713249@sss.pgh.pa.us
Whole thread Raw
In response to Re: New CRC algorithm: Slicing by 8  ("Gregory Maxwell" <gmaxwell@gmail.com>)
Responses Re: New CRC algorithm: Slicing by 8  (Gregory Stark <gsstark@mit.edu>)
Re: New CRC algorithm: Slicing by 8  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-hackers
"Gregory Maxwell" <gmaxwell@gmail.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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: Incorrect behavior with CE and ORDER BY
Next
From: "Gurjeet Singh"
Date:
Subject: Re: New CRC algorithm: Slicing by 8