On Mon, Apr 25, 2011 at 5:04 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, Apr 25, 2011 at 8:14 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Apr 24, 2011, at 1:22 PM, Simon Riggs <simon@2ndQuadrant.com> wrote:
>>> Unlogged tables are a good new feature.
>>
>> Thanks.
>>
>>> I noticed Bruce had mentioned they were the equivalent of NoSQL, which
>>> I don't really accept.
>>
>> Me neither. I thought that was poorly said.
>>
>>> Heap blocks would be zeroed if they were found to be damaged, following a crash.
>>
>> The problem is not so much the blocks that are damaged (e.g. half-written, torn page) but the ones that were never
writtenat all. For example, read page A, read page B, update tuple on page A putting new version on page B, write one
butnot both of A and B out to the O/S, crash. Everything on disk is a valid page, but they are not coherent taken as a
whole. It's normally XLOG replay that fixes this type of situation...
>
> Not really sure it matters what the cause of data loss is, does it?
> The zeroing of the blocks definitely causes data loss but the
> intention is to bring the table back to a consistent physical state,
> not to in any way repair the data loss.
Right, but the trick is how you identify which blocks you need to
zero. You used the word "damaged", which to me implied that the block
had been modified in some way but ended up with other than the
expected contents, so that something like a CRC check might detect the
problem. My point (as perhaps you already understand) is that you
could easily have a situation where every block in the table passes a
hypothetical block-level CRC check, but the table as a whole is still
damaged because update chains aren't coherent. So you need some kind
of mechanism for identifying which portions of the table you need to
zero to get back to a guaranteed-coherent state.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company