Re: PG_dump fatal error (second post) - Mailing list pgsql-admin
From | Jean-Michel Chabanne |
---|---|
Subject | Re: PG_dump fatal error (second post) |
Date | |
Msg-id | 3F1C3FE7.1020906@free.fr Whole thread Raw |
In response to | PG_dump fatal error (second post) ("Nick Fankhauser" <nickf@ontko.com>) |
Responses |
Re: PG_dump fatal error (second post)
|
List | 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@doxpop.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
pgsql-admin by date: