On Sun, 7 Feb 1999, Tom Lane wrote:
> Peter T Mount <peter@retep.org.uk> writes:
> > As expected, the splitting of the file works fine. So the code isn't
> > broken. What I think is happening is that the code extends the table, then
> > tests to see if it's at the 2Gig limit, and when it is, creates the next
> > file for that table.
>
> > However, I think the OS has problems with a file exactly 2Gb in size.
>
> Oh! I didn't realize that we were trying to extend the file to
> *exactly* 2Gb. Indeed that's a very dangerous thing to do: the file
> size in bytes will be 0x80000000, which will appear to be negative when
> viewed as a signed 32-bit integer; unless your OS is very careful about
> signed vs. unsigned arithmetic, it will break.
>
> 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...)
>
> I'd suggest setting the limit a good deal less than 2Gb to avoid any
> risk of arithmetic overflow. Maybe 200000 8K blocks, instead of 262144.
That might be an idea.
I've just re-synced by copy of the cvs source, so I'll set it there, and
we'll know by the morning if it's worked or not.
> And change the comment while you're at it, not just the code ;-)
Will do :-)
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
