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

From Bruce Momjian
Subject Re: pg_dump and large files - is this a problem?
Date
Msg-id 200210221600.g9MG01129921@candle.pha.pa.us
Whole thread Raw
In response to Re: pg_dump and large files - is this a problem?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_dump and large files - is this a problem?  (Philip Warner <pjw@rhyme.com.au>)
Re: pg_dump and large files - is this a problem?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Philip Warner <pjw@rhyme.com.au> writes:
> > None, but it will be compatible with itself (the most we can hope for), and 
> > will work even if shifting is not supported for off_t (how likely is 
> > that?). I agree shift is definitely the way to go if it works on arbitrary 
> > data - ie. it does not rely on off_t being an integer. Can I shift a struct?
> 
> You can't.  If there are any platforms where in fact off_t isn't an
> arithmetic type, then shifting code would break there.  I am not sure
> there are any; can anyone provide a counterexample?
> 
> It would be simple enough to add a configure test to see whether off_t
> is arithmetic (just try to compile "off_t x; x <<= 8;").  How about
>     #ifdef OFF_T_IS_ARITHMETIC_TYPE
>         // cross-platform compatible
>         use shifting method
>     #else
>         // not cross-platform compatible
>         read or write bytes of struct in storage order
>     #endif

It is my understanding that off_t is an integral type and fpos_t is
perhaps a struct.  My fgetpos manual page says:
    The fgetpos() and fsetpos() functions are alternate interfaces equivalent    to ftell() and fseek() (with whence
setto SEEK_SET ), setting and stor-    ing the current value of the file offset into or from the object refer-    enced
bypos. On some (non-UNIX) systems an ``fpos_t'' object may be a    complex object and these routines may be the only
wayto portably reposi-    tion a text stream.
 

I poked around and found this Usenet posting:

http://groups.google.com/groups?q=C+off_t+standard+integral&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=E958tG.8tH%40root.co.uk&rnum=1

stating that while off_t must be arithmetic, it doesn't have to be
integral, meaning it could be float or double, which can't be shifted.

However, since we don't know if we support any non-integral off_t
platforms, and because a configure test would require us to have two
code paths for with/without integral off_t, I suggest we apply my
version of Philip's patch and let's see if everyone can compile it
cleanly.  It does have the advantage of being more portable on systems
that do have integral off_t, which I think is most/all of our supported
platforms.

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


pgsql-hackers by date:

Previous
From: "Igor Georgiev"
Date:
Subject: Re: Security question : Database access control
Next
From: Philip Warner
Date:
Subject: Re: pg_dump and large files - is this a problem?