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: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Philip Warner <pjw(at)rhyme(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Giles Lean <giles(at)nemeton(dot)com(dot)au> |
Subject: | Re: pg_dump and large files - is this a problem? |
Date: | 2002-10-23 22:01:57 |
Message-ID: | 200210232201.g9NM1vf28983@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> > First we need to decide what we want to happen and after that think about
> > how to implement it. Given sizeof(off_t) > sizeof(long) and no fseeko(),
> > we have the following options:
>
> It seems obvious to me that there are no platforms that offer
> sizeof(off_t) > sizeof(long) but have no API for doing seeks with off_t.
> That would be just plain silly. IMHO it's acceptable for us to fail at
> configure time if we can't figure out how to seek.
I would certainly be happy failing at configure time, so we know at the
start what is broken, rather than failures during restore.
> The question is *which* seek APIs we need to support. Are there any
> besides fseeko() and fgetpos()?
What I have added is BSD/OS specific because only on BSD/OS do I know
fpos_t and off_t are the same type. If we come up with other platforms,
we will have to deal with it then.
--
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
From | Date | Subject | |
---|---|---|---|
Next Message | Darko Prenosil | 2002-10-23 22:51:06 | plpq |
Previous Message | mache | 2002-10-23 22:01:29 | Re: crashes with postgresql 7.2.1 on IRIX 6.5 |