From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Page Checksums |
Date: | 2011-12-19 20:18:02 |
Message-ID: | 4EEF9BFA.9000308@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19.12.2011 21:27, Robert Haas wrote:
> To put this another way, we currently WAL-log just about everything.
> We get away with NOT WAL-logging some things when we don't care about
> whether they make it to disk. Hint bits, killed index tuple pointers,
> etc. cause no harm if they don't get written out, even if some other
> portion of the same page does get written out. But as soon as you CRC
> the whole page, now absolutely every single bit on that page becomes
> critical data which CANNOT be lost. IOW, it now requires the same
> sort of protection that we already need for our other critical updates
> - i.e. WAL logging. Or you could introduce some completely new
> mechanism that serves the same purpose, like MySQL's double-write
> buffer.
Double-writes would be a useful option also to reduce the size of WAL
that needs to be shipped in replication.
Or you could just use a filesystem that does CRCs...
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gianni Ciolli | 2011-12-19 20:21:36 | Re: Autonomous subtransactions |
Previous Message | Alvaro Herrera | 2011-12-19 20:14:58 | Re: Autonomous subtransactions |