Re: 16-bit page checksums for 9.2 - Mailing list pgsql-hackers

From Nicolas Barbier
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id CAP-rdTZGLBAsrq1aLO2EytLoUk6Vx3VzaMkjLQeYHLPpBoeQ5Q@mail.gmail.com
Whole thread Raw
In response to Re: 16-bit page checksums for 9.2  (Ants Aasma <ants.aasma@eesti.ee>)
List pgsql-hackers
2011/12/30 Ants Aasma <ants.aasma@eesti.ee>:

> On Thu, Dec 29, 2011 at 6:44 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>
>> positives.  To get this right for a checksum in the page header,
>> double-write would need to be used for all cases where
>> full_page_writes now are used (i.e., the first write of a page after
>> a checkpoint), and for all unlogged writes (e.g., hint-bit-only
>> writes).  There would be no correctness problem for always using
>> double-write, but it would be unnecessary overhead for other page
>> writes, which I think we can avoid.
>
> Unless I'm missing something, double-writes are needed for all writes,
> not only the first page after a checkpoint. Consider this sequence of
> events:
>
> 1. Checkpoint
> 2. Double-write of page A (DW buffer write, sync, heap write)
> 3. Sync of heap, releasing DW buffer for new writes.
>  ... some time goes by
> 4. Regular write of page A
> 5. OS writes one part of page A
> 6. Crash!
>
> Now recovery comes along, page A is broken in the heap with no
> double-write buffer backup nor anything to recover it by in the WAL.

I guess the assumption is that the write in (4) is either backed by
the WAL, or made safe by double writing. ISTM that such reasoning is
only correct if the change that is expressed by the WAL record can be
applied in the context of inconsistent (i.e., partially written)
pages, which I assume is not the case (excuse my ignorance regarding
such basic facts).

So I think you are right.

Nicolas

--
A. Because it breaks the logical sequence of discussion.
Q. Why is top posting bad?


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: SEGFAULT on SELECT * FROM view
Next
From: Andrew Dunstan
Date:
Subject: Re: failed regress test