From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
Cc: | Jim Nasby <jim(at)nasby(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com>, PGSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Protecting against unexpected zero-pages: proposal |
Date: | 2010-11-09 17:31:01 |
Message-ID: | AANLkTimvrd89rdg4UdXRpXH378RJnPt0WevNLSL6vR19@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Nov 9, 2010 at 5:06 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
> So, for getting checksums, we have to offer up a few things:
> 1) zero-copy writes, we need to buffer the write to get a consistent
> checksum (or lock the buffer tight)
> 2) saving hint-bits on an otherwise unchanged page. We either need to
> just not write that page, and loose the work the hint-bits did, or do
> a full-page WAL of it, so the torn-page checksum is fixed
Actually the consensus the last go-around on this topic was to
segregate the hint bits into a single area of the page and skip them
in the checksum. That way we don't have to do any of the above. It's
just that that's a lot of work.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-11-09 17:34:37 | Re: proposal: plpgsql - iteration over fields of rec or row variable |
Previous Message | Tom Lane | 2010-11-09 17:24:44 | Re: DROP TABLESPACE needs crash-resistance |