From: | Peter T Mount <peter(at)retep(dot)org(dot)uk> |
---|---|
To: | Stupor Genius <stuporg(at)erols(dot)com> |
Cc: | Pgsql-Hackers <pgsql-hackers(at)postgresql(dot)org>, tgl(at)sss(dot)pgh(dot)pa(dot)us |
Subject: | RE: [HACKERS] Problems with >2GB tables on Linux 2.0 |
Date: | 1999-02-07 21:02:32 |
Message-ID: | Pine.LNX.4.04.9902072059110.6820-100000@maidast.retep.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)retep(dot)org(dot)uk
Main Homepage: http://www.retep.org.uk
PostgreSQL JDBC Faq: http://www.retep.org.uk/postgres
Java PDF Generator: http://www.retep.org.uk/pdf
From | Date | Subject | |
---|---|---|---|
Next Message | Jan Wieck | 1999-02-07 21:06:03 | Re: [HACKERS] v6.4.3 ? |
Previous Message | The Hermit Hacker | 1999-02-07 20:45:03 | Re: [HACKERS] v6.4.3 ? |