> For that matter it's not impossible that our own code contains similar
> problems, if it does much calculating with byte offsets into the file.
> (The pushups that darrenk had to do in order to calculate RELSEG_SIZE
> in the first place should have suggested to him that running right at
> the overflow limit was not such a hot idea...)
Not my code to begin with...
RELSEG_SIZE was always there hard-coded to 262144 to assume the block
size would be 8k. At the time of my changes, I didn't think thru what
it was for, I only changed the code that was there to calculate it and
get the same value as before for variable disc block sizes.
I agree that running right at the limit is a Bad Thing, but analyzing
that wasn't my main area of concern with that patch.
darrenk