Re: pg_dump and large files - is this a problem? - Mailing list pgsql-hackers

From Philip Warner
Subject Re: pg_dump and large files - is this a problem?
Date
Msg-id 5.1.0.14.0.20021023125907.028f7a40@mail.rhyme.com.au
Whole thread Raw
In response to Re: pg_dump and large files - is this a problem?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: pg_dump and large files - is this a problem?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: pg_dump and large files - is this a problem?  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
At 10:46 PM 22/10/2002 -0400, Bruce Momjian wrote:
>Uh, not exactly.  I have off_t as a quad, and I don't have fseeko, so
>the above conditional doesn't work. I want to use off_t, but can't use
>fseek().

Then when you create dumps, they will be invalid since I assume that ftello 
is also broken in the same way. You need to fix _getFilePos as well. And 
any other place that uses an off_t needs to be looked at very carefully. 
The code was written assuming that if 'hasSeek' was set, then we could 
trust it.

Given that you say you do have support for some kind of 64 bt offset, I 
would be a lot happier with these changes if you did something akin to my 
original sauggestion:

#if defined(HAVE_FSEEKO)
#define FILE_OFFSET off_t
#define FSEEK fseeko
#elseif defined(HAVE_SOME_OTHER_FSEEK)
#define FILE_OFFSET some_other_offset
#define FSEEK some_other_fseek
#else
#define FILE_OFFSET long
#define FSEEK fseek
#end if

...assuming you have a non-broken 64 bit fseek/tell pair, then this will 
work in all cases, and make the code a lot less ugly (assuming of course 
the non-broken version can be shifted).



----------------------------------------------------------------
Philip Warner                    |     __---_____
Albatross Consulting Pty. Ltd.   |----/       -  \
(A.B.N. 75 008 659 498)          |          /(@)   ______---_
Tel: (+61) 0500 83 82 81         |                 _________  \
Fax: (+61) 0500 83 82 82         |                 ___________ |
Http://www.rhyme.com.au          |                /           \|                                 |    --________--
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_dump and large files - is this a problem?
Next
From: Bruno Wolff III
Date:
Subject: Re: One 7.3 item left