Re: 16-bit page checksums for 9.2

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <simon(at)2ndQuadrant(dot)com>
Cc: <andres(at)anarazel(dot)de>,<aidan(at)highrise(dot)ca>, <stark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 16-bit page checksums for 9.2
Date: 2012-01-04 07:12:43
Message-ID: 4F03A78B02000025000442D6@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Kevin Grittner" wrote:

> if we define sum1 and sum2 as uint I don't see how we can get an
> overflow with 8k byes

I feel the need to amend that opinion.

While sum1 only needs to hold a maximum of (BLCKSZ * 255), which
would be adequate for a BLCKSZ up to 16 MB, sum2 needs to hold up to
a maximum of ((BLCKSZ * (BLCKSZ + 1) / 2) * 255) so a 32-bit unsigned
isn't even good for an 8 KB block size. A uint64 for sum2 can handle
BLCKSZ up to 256 MB. So we could define sum1 as uint (which is
presumably either uint32 or uint64) and sum2 as uint64 and for a
BLCKSZ up toe 16 MB we still don't need to find the modulo 255
numbers until we're done adding things up.

Does anyone think we need to support anything bigger than that?
Making them both uint64 would support a BLCKSZ up to 256 MB without
needing to do the division inside the loop. but it might be slightly
slower on 32-bit builds.

-Kevin

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2012-01-04 07:24:32 Re: BGWriter latch, power saving
Previous Message Amit Kapila 2012-01-04 06:42:26 Regarding Checkpoint Redo Record