On Mon, Nov 17, 2008 at 08:41:20AM -0500, Aidan Van Dyk wrote:
> * Greg Stark <greg.stark@enterprisedb.com> [081117 03:54]:
> > [sorry for top-posting - damn phone]
> >
> > I thought of saying that too but it doesn't really solve the problem.
> > Think of what happens if someone sets a hint bit on a dirty page.
>
> If the page is dirty from a "real change", then it has a WAL backup block
> record already, so the torn-page on disk is going to be fixed with the wal
> replay ... *because* of the torn-page problem already being "solved" in PG.
Aah, I thought the problem was that someone updating a tuple won't
write out the whole page to WAL, only a delta. Then again, maybe I
understood it wrong.
> The tradeoff for CRC is:
>
> 1) Are hint-bits "worth saving"? (noting that with CRC the goal is the
> ability of detecting blocks that aren't *exactly* as we wrote them)
Worth saving? No. Does it matter if they're wrong? Yes. If the
XMIN_COMMITTED bit gets set incorrectly the tuple may appear even when
it shouldn't. Put another way, accedently having a one converted to a
zero is not a problem. Having a zero become a one though, is probably
bad.
> 2) Are hint-bits "nice, but not worth IO" (noting that this case can be
> mitigated to only pages which are hint-bit *only* changed, not dirty with
> already-wal-logged changes)
That's a long running debate. Hint bits do save I/O, the question is
the tradeoff.
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Please line up in a tree and maintain the heap invariant while
> boarding. Thank you for flying nlogn airlines.