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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
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 04:29:39
Message-ID: 200210230429.g9N4TdS17935@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Sounds messy. Let me see if I can code up an fseeko/ftello for BSD/OS
and add that to /port. No reason to hold up beta for that, though.

I wonder if any other platforms have this limitation. I think we need
to add some type of test for no-fseeko()/ftello() and sizeof(off_t) >
sizeof(long). This fseeko/ftello/off_t is just too fluid, and the
failure modes too serious.

---------------------------------------------------------------------------

Philip Warner wrote:
> 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 |/
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2002-10-23 04:32:56 Re: pg_dump and large files - is this a problem?
Previous Message Chad R. Larson 2002-10-23 04:21:23 Re: Security question : Database access control