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<t...@sss.pgh.pa.us> wrote: > >> Merlin Moncure<mmonc...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
