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

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Philip Warner <pjw(at)rhyme(dot)com(dot)au>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Giles Lean <giles(at)nemeton(dot)com(dot)au>, PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_dump and large files - is this a problem?
Date: 2002-10-22 16:00:01
Message-ID: 200210221600.g9MG01129921@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Philip Warner <pjw(at)rhyme(dot)com(dot)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 set to SEEK_SET ), setting and stor-
ing the current value of the file offset into or from the object refer-
enced by pos. On some (non-UNIX) systems an ``fpos_t'' object may be a
complex object and these routines may be the only way to 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(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 Hosen, John 2002-10-22 16:11:35 'epoch'::timestamp and Daylight Savings
Previous Message Tom Lane 2002-10-22 15:35:25 Re: Security question : Database access control