Re: Protecting against unexpected zero-pages: proposal - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Protecting against unexpected zero-pages: proposal
Date
Msg-id 25661.1289233014@sss.pgh.pa.us
Whole thread Raw
In response to Re: Protecting against unexpected zero-pages: proposal  (Aidan Van Dyk <aidan@highrise.ca>)
Responses Re: Protecting against unexpected zero-pages: proposal
List pgsql-hackers
Aidan Van Dyk <aidan@highrise.ca> writes:
> Getting back to the checksum debate (and this seems like a
> semi-version of the checksum debate), now that we have forks, could we
> easily add block checksumming to a fork?  IT would mean writing to 2
> files but that shouldn't be a problem, because until the checkpoint is
> done (and thus both writes), the full-page-write in WAL is going to
> take precedence on recovery.

Doesn't seem like a terribly good design: damage to a checksum page
would mean that O(1000) data pages are now thought to be bad.

More generally, this re-opens the question of whether data in secondary
forks is authoritative or just hints.  Currently, we treat it as just
hints, for both FSM and VM, and thus sidestep the problem of
guaranteeing its correctness.  To use a secondary fork for checksums,
you'd need to guarantee correctness of writes to it.  This is the same
problem that index-only scans are hung up on, ie making the VM reliable.
I forget whether Heikki had a credible design sketch for making that
happen, but in any case it didn't look easy.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: timestamp of the last replayed transaction
Next
From: Pavel Stehule
Date:
Subject: Re: SQL2011 and writeable CTE