Re: PG_dump fatal error (second post)

Поиск
Список
Период
Сортировка
От Jean-Michel Chabanne
Тема Re: PG_dump fatal error (second post)
Дата
Msg-id 3F1C3FE7.1020906@free.fr
обсуждение исходный текст
Ответ на PG_dump fatal error (second post)  ("Nick Fankhauser" <nickf@ontko.com>)
Ответы Re: PG_dump fatal error (second post)  ("Nick Fankhauser" <nickf@ontko.com>)
Список 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 по дате отправления:

Предыдущее
От: "Nick Fankhauser"
Дата:
Сообщение: Re: common_fields: permission denied
Следующее
От: "Nick Fankhauser"
Дата:
Сообщение: Re: PG_dump fatal error (second post)