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

From: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
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:50:47
Message-ID: 5.1.0.14.0.20021024114405.02902f48@mail.rhyme.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At 09:36 PM 23/10/2002 -0400, Bruce Momjian wrote:
>We are going to need to either get fseeko workarounds for
>those, or disable those features in a meaningful way.

????? if we have not got a 64 bit seek function of any kind, then use a 32
bit seek - the features don't need to be disabled. AFAICT, this is a
non-issue: no 64 bit seek means no large files.

I'm not sure we should even worry about it, but if you are genuinely
concerned that we have no 64 bit seek call, but we do have files > 4GB,
then If you really want to disable seek, just modify the code that sets
'hasSeek' - don't screw around with every seek call. But only modify clear
it if the file is > 4GB.

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2002-10-24 01:51:42 Re: pg_dump and large files - is this a problem?
Previous Message Bruce Momjian 2002-10-24 01:45:55 Re: pg_dump and large files - is this a problem?