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: Peter Eisentraut <peter_e(at)gmx(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Giles Lean <giles(at)nemeton(dot)com(dot)au>
Subject: Re: pg_dump and large files - is this a problem?
Date: 2002-10-24 01:36:35
Message-ID: 200210240136.g9O1aZH23848@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Philip Warner wrote:
> At 05:50 PM 23/10/2002 -0400, Bruce Momjian wrote:
> >Looking at the pg_dump code, it seems the fseeks are optional in there
> >anyway because it already has code to read the file sequentially rather
>
> But there are features that are not available if it can't seek: eg. it will
> not restore in a different order to that in which it was written; it will
> not dump data offsets in the TOC so dump files can not be restored in
> alternate orders; restore times will be large for a single table (it has to
> read the entire file potentially).

OK, that helps. We just got a list of 2 other OS's without fseeko and
with large file support. Any NetBSD before Auguest 2002 has that
problem. We are going to need to either get fseeko workarounds for
those, or disable those features in a meaningful way.

--
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 Bruce Momjian 2002-10-24 01:37:08 Re: pg_dump and large files - is this a problem?
Previous Message Philip Warner 2002-10-24 01:33:50 Re: pg_dump and large files - is this a problem?