Re: pg_dump failure in tar format.

From: "Nick Fankhauser" <nickf(at)ontko(dot)com>
To: "Philip Warner" <pjw(at)rhyme(dot)com(dot)au>, <pgsql-bugs(at)postgresql(dot)org>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: pg_dump failure in tar format.
Date: 2003-08-02 17:16:43
Message-ID: NEBBLAAHGLEEPCGOBHDGOEEDHOAA.nickf@ontko.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Phillip-

Thanks for the explanation of how this works- I'll check it out & let you
know if that is the source of the problem in my case. If it is, perhaps I
can submit a short paragraph for the documentation that will clue people in
if they run into this in the future. I suppose it could be handled more
gracefully in the code by specifying a tempfile location as you suggest, but
since it isn't really broken, I'd vote that documenting the potential
constraint is a valid and time-saving "fix" that will let you put off
messing with the code until you have a more compelling reason to work with
it.

-NF

> -----Original Message-----
> From: Philip Warner [mailto:pjw(at)rhyme(dot)com(dot)au]
> Sent: Friday, August 01, 2003 6:37 PM
> To: nickf(at)ontko(dot)com; pgsql-bugs(at)postgresql(dot)org
> Subject: Re: [BUGS] pg_dump failure in tar format.
>
>
> At 02:47 PM 1/08/2003 -0500, Nick Fankhauser - Doxpop wrote:
> >pg_dump: [tar archiver] could not write to tar member (wrote 39,
> attempted
> >166)
>
> One of the nasty features of TAR format is that it needs to know the file
> size before adding it to the archive. As a result, pg_dump stores
> the file
> in the /tmp directory before moving it to the actual output file.
> For huge
> files, this means /tmp must be able to cope with the uncompressed size of
> the largest table. It's horrible, I know, which is why I use -Fc, but I'd
> guess this is the cause of your error.
>
> It uses tmpfile() to get a temp file, so I can't see a simple way to test
> this, unless you can free up 2+GB in /tmp?
>
> Please let me know if this is the cause, and if you can not test
> it, I will
> try to send a patch to (temporarily) avoid using tmpfile(). Ideally, I
> suppose pg_dump should support the ability to override the
> tmpfile() location.
>
> Bye for now,
>
> Philip
>
>
>
>
> ----------------------------------------------------------------
> Philip Warner | __---_____
> Albatross Consulting Pty. Ltd. |----/ - \
> (A.B.N. 75 008 659 498) | /(@) ______---_
> Tel: (+61) 0500 83 82 81 | _________ \
> Fax: (+61) 03 5330 3172 | ___________ |
> Http://www.rhyme.com.au | / \|
> | --________--
> PGP key available upon request, | /
> and from pgp5.ai.mit.edu:11371 |/
>

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2003-08-04 00:04:42 Re: PostgreSQL 7.3.3 with pgcrypto on FreeBSD 5.1
Previous Message Sean Chittenden 2003-08-02 06:12:59 Re: PostgreSQL 7.3.3 with pgcrypto on FreeBSD 5.1