Re: New CRC algorithm: Slicing by 8

On Tue, 2006-10-24 at 15:42 -0400, Gregory Stark wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
> > 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.
>
> Actually I think we can deal with torn pages in the WAL more easily than in
> database files anyways. In database files we need to get the entire page
> correctly one way or the other so we need full_page_writes in order to be deal
> properly.
>
> 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.

Right, but I'm only suggesting using this if your safe from torn pages
anyhow. I'm not suggesting anyone does wal_checksum = off when
full_page_writes = on.

I do think you're right: we're much less exposed by a torn page in WAL
than we are for the stable database.

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.

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