Re: PG_dump fatal error (second post)

From: Jean-Michel Chabanne <jeanmichel(dot)chabanne(at)free(dot)fr>
To: nickf(at)ontko(dot)com
Cc: pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: PG_dump fatal error (second post)
Date: 2003-07-21 19:32:55
Message-ID: 3F1C3FE7.1020906@free.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Nick Fankhauser a écrit :

>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)
>
>
prod.dump.tar is the result of pg_dump, not a command, as for your text sample below.
"pg_dump -Ft prod > prod.dump.tar" would be better.

>-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(at)doxpop(dot)com Phone 1.765.965.7363 Fax 1.765.962.9788
>doxpop - Court records at your fingertips - http://www.doxpop.com/
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
>
>

--
Jean-Michel Chabanne
77450 MONTRY (FRANCE)
48" 54' N - 2" 49' E
Powered by Linux

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Nick Fankhauser 2003-07-21 19:57:02 Re: PG_dump fatal error (second post)
Previous Message Nick Fankhauser 2003-07-21 16:22:50 Re: common_fields: permission denied