Re: [Firebird-devel] temp files >2GB

[John B. <bel...@cs...>]

On Monday, July 30, 2001, at 11:15 AM, Ann W. Harrison wrote:

> At 12:57 PM 7/30/2001 -0400, Leyne, Sean wrote:
>
>> At this point, I still don't think that there is a 64bit I/O problem
>> with the engine.  Although there _may_ be a problem with large sort
>> results.
>
> I just had a very quick look at SORT.C and DLS.C, both in JRD.  SORT
> certainly does an lseek on its temp file to position to the end.
> Probably DLS should not let SORT allocate a temp file over 2Gb,
> regardless of the space available.  Alternately, SORT could be
> taught to use lseek32 or equivalent.

Does it help that all the parameter to functions (internal to SORT and 
externally visible in DLS) use ULONG arguments?  The ULONGs in DLS don't 
matter if the calling code is smart enough to break the request for > 
2GB scratch files into multiple calls to DLS.  But what about internally 
in SORT?  I didn't see SORT using an SINT64 (or long long) to compute 
the size of the scratch file needed.  That may cause a problem.  Another 
issue is the use of a ULONG to hold the length of the file needed.  In 
most lseek calls I know of the offset parameter is signed, limiting the 
file to 2 GB.  If we are using an ULONG internally we might think we 
allocated a 3 GB file and then be surprised later.

-John