PG_dump fatal error (second post) - Mailing list pgsql-admin

From Nick Fankhauser
Subject PG_dump fatal error (second post)
Date
Msg-id NEBBLAAHGLEEPCGOBHDGOEJMHMAA.nickf@ontko.com
Whole thread Raw
Responses Re: PG_dump fatal error (second post)  (Dani Oderbolz <oderbolz@ecologic.de>)
Re: PG_dump fatal error (second post)  (Jean-Michel Chabanne <jeanmichel.chabanne@free.fr>)
List pgsql-admin
Hello-

I'm reposting this problem because I didn't receive any responses to the
first post that led to a resolution- Perhaps this is a bug, but I'll give it
another chance here before promoting it to the bugs list.

Since sending the information below, I've set up a nearly identical system
on another box and loaded the same database there to ensure that my problem
isn't simply due to hardware or bit of corruption in my installed software.
I still get exactly the same message on the second box, so I'm practically
certain that this is a predictably repeatable problem with pg_dump.

Here's the original post:

I'm getting the following error message:

pg_dump: [tar archiver] could not write to tar member (wrote 39, attempted
166)

Here are the particulars:

-I'm running this command: "pg_dump -Ft prod | prod.dump.tar" (The database
is named prod)

-The dump gets about 1/4 of the way through, and then gives me the error
message and dies.

-I'm running PostgreSQL version 7.3.2.

-There is plenty of disk space available.

-The same command on the same database and server with same specs worked
last week when I was on V7.2.1.

-Since upgrading, more data has been added, but the structure of the
database is unchanged.

-Using the -v switch shows me that it always quits on the same table, but
otherwise adds no new information.

-The part of the error message in parentheses changes on each run. For
instance, on the last run, I got  "(wrote 64, attempted 174)" The rest of
the message remains consistent.

-The table it quits on is fairly large- about 2.6GB. It is both "wide"
because it contains a text field that is usually a few sentences of text,
and "long", containing 9,137,808 records. This is also the only table in our
database that is split into multiple files.

-A text dump using this command works fine: "pg_dump prod > prod.dump.text"

I found a reference to this message in the admin list archives on 3/28/2003,
but it was in the context of a database containing large blobs (mine has no
blobs), and the suggestion was to upgrade to 7.3. I couldn't find a
resolution in that thread, so I'm not sure if it ever got worked out.

Any thoughts??

Thanks!
   -Nick

---------------------------------------------------------------------
Nick Fankhauser

    nickf@doxpop.com  Phone 1.765.965.7363  Fax 1.765.962.9788
doxpop - Court records at your fingertips - http://www.doxpop.com/


pgsql-admin by date:

Previous
From: The Hermit Hacker
Date:
Subject: Re: news.us.postgresql.org
Next
From: Bruce Momjian
Date:
Subject: Re: Renaming a DB