On Mon, Nov 17, 2008 at 08:41:20AM -0500, Aidan Van Dyk wrote: > * Greg Stark <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines.
signature.asc
Description: Digital signature
