From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
Cc: | "Gurjeet Singh" <singh(dot)gurjeet(at)gmail(dot)com>, "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New CRC algorithm: Slicing by 8 |
Date: | 2006-10-24 13:37:57 |
Message-ID: | 7962.1161697077@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Mon, 2006-10-23 at 15:12 -0400, Tom Lane wrote:
>> There are actually three checks used to detect end of WAL: zero record
>> length, invalid checksum, and incorrect back-pointer. Zero length is
>> the first and cleanest-looking test, but AFAICS we have to have both of
>> the others to avoid obvious failure modes.
> The checksum protects from torn pages and disk errors. If you have
> full_page_writes set then you already believe yourself safe from torn
> pages and your disks could also already be CRC-checking the data.
No, because unlike tuples, WAL records can and do cross page boundaries.
Unless you're prepared to posit that your system never crashes at all,
you have to be able to detect the case where you've got a good front
half of a WAL record and non-matching data in the next page. The two
halves could be written out in widely separated write()s, indeed might
never have been simultaneously resident in the WAL buffers at all.
> CRC-checked disks are actually the industry norm and have been for
> around 5 years.
Huh? Disks have ALWAYS had CRCs, and this is in any case utterly
irrelevant to the database-crash risk.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-10-24 13:39:34 | Re: [HACKERS] COPY does not work with regproc and aclitem |
Previous Message | Hannu Krosing | 2006-10-24 13:29:36 | Re: Replication documentation addition |