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

Here is a modified version of Philip's patch that has the changes Tom
suggested; treating off_t as an integral type. I did light testing on
my BSD/OS machine that has 8-byte off_t but I don't have 4 gigs of free
space to test larger files.

ftp://candle.pha.pa.us/pub/postgresql/mypatches/pg_dump

Can others test?

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

Tom Lane wrote:
> Philip Warner <pjw(at)rhyme(dot)com(dot)au> writes:
> > then checking the first byte? This should give me the endianness, and makes
> > a non-destructive write (not sure it it's important). Currently the
> > commonly used code does not rely on off_t arithmetic, so if possible I'd
> > like to avoid shift. Does that sound reasonable? Or overly cautious?
>
> I think it's pointless. Let's assume off_t is not an arithmetic type
> but some weird struct dreamed up by a crazed kernel hacker. What are
> the odds that dumping the bytes in it, in either order, will produce
> something that's compatible with any other platform? There could be
> padding, or the fields might be in an order that doesn't match the
> byte order within the fields, or something else.
>
> The shift method requires *no* directly endian-dependent code,
> and I think it will work on any platform where you have any hope of
> portability anyway.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

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