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

From Simon Riggs
Subject Re: New CRC algorithm: Slicing by 8
Date
Msg-id 1161940268.11568.9.camel@silverbirch.site
Whole thread Raw
In response to Re: New CRC algorithm: Slicing by 8  ("Zeugswetter Andreas ADI SD" <ZeugswetterA@spardat.at>)
Responses Re: New CRC algorithm: Slicing by 8  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
On Fri, 2006-10-27 at 10:54 +0200, Zeugswetter Andreas ADI SD wrote:
> >> In the WAL we just need to be able to detect torn pages and stop 
> >> reading WAL at that point. That's easier and doesn't really need a 
> >> CRC. We could just adopt the Sybase strategy of storing a unique id 
> >> number every 512 bytes throughout the WAL page. If those numbers
> don't 
> >> match then we have a torn page; the system crashed at that point and
> we should stop reading WAL pages.
> 
> > I've looked into this in more depth following your 
> > suggestion: I think it seems straightforward to move the 
> > xl_prev field from being a header to a trailer. That way when 
> > we do the test on the back pointer we will be assured that 
> > there is no torn page effecting the remainder of the xlrec. 
> > That would make it safer with wal_checksum = off.
> 
> I do not think we can assume any order of when a block is written to
> disk.
> 
> I think all this can only be used on OS and hardware, that can guarantee
> that what is written by one IO call (typically 8k) from pg is safe.
> Those combinations do exist, so I think we want the switch.

OK, good.
... but from the various comments I'll not bother moving xl_prev to be a
trailer; I'll just leave that where it is now.

> Putting xl_prev to the end helps only for direct IO WAL sync methods,
> else we would need it on every page.

[There is already an XLogRecPtr on each 8k page.]

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




pgsql-hackers by date:

Previous
From: dakotali kasap
Date:
Subject: printing the query plan?
Next
From: Martijn van Oosterhout
Date:
Subject: Re: printing the query plan?