Re: pg_dump and large files - is this a problem?

Philip Warner wrote:
> At 01:02 AM 23/10/2002 -0400, Bruce Momjian wrote:
> 
> >OK, you are saying if we don't have fseeko(), there is no reason to use
> >off_t, and we may as well use long.  What limitations does that impose,
> >and are the limitations clear to the user.
> 
> What I'm saying is that if we have not got fseeko then we should use any 
> 'seek-class' function that returns a 64 bit value. We have already made the 
> assumption that off_t is an integer; the same logic that came to that 
> conclusion, applies just as validly to the other seek functions.

Oh, I see, so try to use fsetpos/fgetpos?  I can write wrappers for
those to look like fgetpos/fsetpos and put it in /port.

> Secondly, if there is no 64 bit 'seek-class' function, then we should 
> probably use a size_t, but a long would probably be fine too. I am not 
> particularly attached to this part; long, int etc etc. Whatever is most 
> likely to return an integer and work with whatever function we choose.
> 
> As to implications: assuming they are all integers (which as you know I 
> don't like), we should have no problems.
> 
> If a system does not have any function to access 64 bit file offsets, then 
> I'd say they are pretty unlikely to have files > 2GB.

OK, my OS can handle 64-bit files, but has only fgetpos/fsetpos, so I
could get that working.  The bigger question is what about OS's that
have 64-bit off_t/files but don't have any seek-type functions.  I did
research to find mine, but what about others that may have other
variants?

I think you are right that we have to not use off_t and use long if we
can't find a proper 64-bit seek function, but what are the failure modes
of doing this?  Exactly what happens for larger files?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073