On Wed, 2010-12-22 at 22:08 +0200, Heikki Linnakangas wrote:
> On 22.12.2010 18:12, Merlin Moncure wrote:
> > On Wed, Dec 22, 2010 at 11:06 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> >> Merlin Moncure<mmoncure@gmail.com> writes:
> >>> well, simon's point that hint bits complicate checksum may nor may not
> >>> be the case, but no hint bits = less i/o = less checksumming (unless
> >>> you checksum around the hint bits).
> >>
> >> I think you're optimistically assuming the extra clog accesses don't
> >> cost any I/O.
> >
> > right, but clog is much more highly packed which is both a good and a
> > bad thing.
>
> As a sidenote: note that the clog is not currently CRC'd.
Good point, thanks for mentioning it.
With 64kB of clog buffers and potentially 8 GB of shared_buffers, which
is about 10^5 more RAM for shared_buffers. So a protection mechanism for
shared_buffers will trap about 99.999% of RAM errors.
We might say that an error in clog could have a serious effect, and I
would agree. I don't see a way around that though, except for a CRC
check when we write to disk.
My understanding is that the context switch storms were because of the
I/O involved with thrashing the clog buffers. (Well, actually, I think
it was subtrans, but sane difference). To solve that, we could just swap
them out to shared_buffers with usage = 5 rather than evict them.
-- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services