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

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Giles Lean <giles(at)nemeton(dot)com(dot)au>
Subject: Re: pg_dump and large files - is this a problem?
Date: 2002-10-23 03:06:08
Message-ID: 5.1.0.14.0.20021023125907.028f7a40@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 |/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-10-23 03:21:41 Re: Memory leaks
Previous Message Bruce Momjian 2002-10-23 02:46:17 Re: pg_dump and large files - is this a problem?