Re: 16-bit page checksums for 9.2 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: 16-bit page checksums for 9.2
Date
Msg-id 4F03A78B02000025000442D6@gw.wicourts.gov
Whole thread Raw
In response to 16-bit page checksums for 9.2  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: 16-bit page checksums for 9.2  (Alvaro Herrera <alvherre@commandprompt.com>)
List 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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: BGWriter latch, power saving
Next
From: Heikki Linnakangas
Date:
Subject: Re: BGWriter latch, power saving