Re: Block-level CRC checks

* Alvaro Herrera <alvherre(at)commandprompt(dot)com> [081002 16:18]:

> > And, this still seems to have an issue with WAL, unless Simon's
> > original idea somehow included recording hint bit settings/dirtying
> > the page in WAL.
>
> I have to admit I don't remember exactly how it worked :-) I think the
> idea was avoiding setting the page dirty until a certain number of hint
> bit setting operations had been done (which I think means it's not
> useful for the present purpose).

How crazy would I be to wonder about the performance impact of doing the
full_page_write xlog block backups at buffer dirtying time
(MarkBufferDirty and SetBufferCommitInfoNeedsSave), instead of at
XLogInsert?

A few thoughts, quite possible not true:

* The xlog backup block records don't need to be synced to disk at the
time of the dirty but they can be synced along with stuff behind it,
although it *needs* to be synced by the time the buffer write() comes
long, otherwise we haven't fixed our torn page probem, so practically,
we may need to sync it for guarentees
* OLAP workloads that handle bulk insert/update/delete are probably
running with full_page_writes off, so don't pay the penalty of extra
xlog writing on all the hint-bits being set
* OLTP workloads with full_page_writes on would have some extra
full_page_writes, but I have a feeling that most dirtied buffers in
OLTP systems are going to get changed by more than just hint-bits soon
eonugh anyways, so it's not a huge net increase
* Slow systems that aren't high-velocity can probably spare a bit more
Xlog bandwith anyways...

But my experience is limitted to my small-scale databases...

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