Re: Block-level CRC checks

Поиск
Список
Период
Сортировка
От Aidan Van Dyk
Тема Re: Block-level CRC checks
Дата
Msg-id 20081117153653.GU31053@yugib.highrise.ca
обсуждение исходный текст
Ответ на Re: Block-level CRC checks  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: Block-level CRC checks  (Alvaro Herrera <alvherre@commandprompt.com>)
Список pgsql-hackers
* Martijn van Oosterhout <kleptog@svana.org> [081117 10:15]:
> 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.

I'm no expert, but from my understanding of xlog.c, the WAL record is a "delta"
type record (i.e with MVCC, a new tuple, but HOT complicated this), but the WAL
makes a "backup block record" of the block the WAL modifies hasn't been written
since the last checkpoint.  This "backup block" is what saves postgres from the
torn-page problem on crash/recovery.

On pages with "only hint-bit updates", the torn-page problem was never an issue
because either the old or new parts of the pages are both valid on recovery,
you just may need to re-calculate a hint-bit again.

> > 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.

Yes, and this difference is why not WAL-logging hint bits (and allowing
torn-pages to possibley appear) is been safe and never been a problem.

But if you're doing a CRC on the page, then they are suddenenly just as equally
important as a "real change"

> > 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.

And I don't think anyone's going to have a good answer either way unless we get
real numbers.  But I don't know of any way to get at these numbers right now.

1) How many writes happen on buffer pages that are "hint dirty" but not "really  dirty"?

2) How much IO would writing the WAL records "hint bits" on every page write  take up?

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCHES] Infrastructure changes for recovery (v8)
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PATCHES] Infrastructure changes for recovery (v8)