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.
>
> 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.

Let me see if I can be clearer. With shifting off_t, if that fails, we
will find out right away, at compile time. I think that is acceptable.

What I am concerned about are cases that fail at runtime, specifically
during a restore of a >2gig file. In my reading of the code, those
failures will be silent or will produce unusual error messages. I don't
think we can ship code that has strange failure modes for data restore.

Now, if someone knows those failure cases, I would love to hear about
it. If not, I will dig into the code today and find out where they are.

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