| From: | Gregory Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Gregory Maxwell" <gmaxwell(at)gmail(dot)com>, "mark(at)mark(dot)mielke(dot)cc" <mark(at)mark(dot)mielke(dot)cc>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "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 19:42:51 |
| Message-ID: | 87k62ph550.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ron Mayer | 2006-10-24 19:53:23 | Re: [SPAM?] Re: Asynchronous I/O Support |
| Previous Message | Joshua D. Drake | 2006-10-24 19:34:17 | Re: [HACKERS] Replication documentation addition |