Skip site navigation (1) Skip section navigation (2)

Re: New CRC algorithm: Slicing by 8

From: "Zeugswetter Andreas ADI SD" <ZeugswetterA(at)spardat(dot)at>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>,"Gregory Stark" <gsstark(at)mit(dot)edu>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,"Gregory Maxwell" <gmaxwell(at)gmail(dot)com>,<mark(at)mark(dot)mielke(dot)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-27 08:54:03
Message-ID: E1539E0ED7043848906A8FF995BDA57901726A5B@m0143.s-mxs.net (view raw or flat)
Thread:
Lists: pgsql-hackers
>> 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. 
Putting xl_prev to the end helps only for direct IO WAL sync methods,
else we would need it on every page.

Andreas

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2006-10-27 08:54:31
Subject: Re: Deadlock with pg_dump?
Previous:From: Andrew DunstanDate: 2006-10-27 08:50:37
Subject: Re: bug in on_error_rollback !?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group