From: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [WIP] Double-write with Fast Checksums |
Date: | 2012-01-12 01:38:48 |
Message-ID: | CAC_2qU8UqcGQXPyDYfT3twHSHEs6Vusr_V_W6E+uBt90HP3dsg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 11, 2012 at 7:09 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> The question is how you prevent torn pages when a slave server crashes
> during replay. Right now, the presence of FPIs in the WAL stream,
> together with the requirement that replay restart from a checkpoint,
> is sufficient to guarantee that any torn pages will be fixed up. If
> you remove FPIs from WAL and don't transmit some substitute information,
> ISTM you've lost protection against slave server crashes.
This double-write stragegy is all an attempt to make "writes" durable.
You remove the FPW from the WAL stream only because you're "writes"
are make durable using some other stragegy, like the double-write.
Any standby will need to be using some stragegy to make sure it's
writes are durable, namely, the same double-write.
So on a standby crash, it will replay whatever FPWs it has in the
double-write buffer it has accumulated to make sure it's writes were
consistent. Exactly as the master would do.
a.
--
Aidan Van Dyk Create like a god,
aidan(at)highrise(dot)ca command like a king,
http://www.highrise.ca/ work like a slave.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-01-12 01:48:03 | measuring spinning |
Previous Message | Tom Lane | 2012-01-12 00:58:02 | Re: WIP -- renaming implicit sequences |