| From: | "Stupor Genius" <stuporg(at)erols(dot)com> |
|---|---|
| To: | "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Cc: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Subject: | RE: [HACKERS] Problems with >2GB tables on Linux 2.0 |
| Date: | 1999-02-07 18:39:59 |
| Message-ID: | 000001be52c9$440f2560$5698accf@darren |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 1999-02-07 18:46:42 | Oops, I seem to have changed UNION's behavior |
| Previous Message | Tom Lane | 1999-02-07 18:23:44 | Re: [HACKERS] v6.4.3 ? |