On Sun, 7 Feb 1999, Stupor Genius wrote:
> > 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.
I agree with you. I think that the original error stemmed from when
RELSEG_SIZE was originally set.
Anyhow, I'm about to start the test, using RELSEG_SIZE set to 243968 which
works out to be 1.6Gb. That should stay well away from the overflow
problem.
Peter
-- Peter T Mount peter@retep.org.uk Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgresJava PDF Generator: http://www.retep.org.uk/pdf