| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Aidan Van Dyk <aidan(at)highrise(dot)ca> |
| Cc: | 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 15:27:53 |
| Message-ID: | AANLkTimu5Ac21xu366f+8sXYwWXs_RPmJVd84XSqLFEx@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Nov 9, 2010 at 3:25 PM, Greg Stark <gsstark(at)mit(dot)edu> wrote:
> Oh, I'm mistaken. The problem was that buffering the writes was
> insufficient to deal with torn pages. Even if you buffer the writes if
> the machine crashes while only having written half the buffer out then
> the checksum won't match. If the only changes on the page were hint
> bit updates then there will be no full page write in the WAL log to
> repair the block.
Huh, this implies that if we did go through all the work of
segregating the hint bits and could arrange that they all appear on
the same 512-byte sector and if we buffered them so that we were
writing the same bits we checksummed then we actually *could* include
them in the CRC after all since even a torn page will almost certainly
not tear an individual sector.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Viktor Valy | 2010-11-09 15:50:09 | TODO Alter Table Rename Constraint |
| Previous Message | Greg Stark | 2010-11-09 15:25:23 | Re: Protecting against unexpected zero-pages: proposal |