Re: Emergency - Need assistance

Поиск
Список
Период
Сортировка
От warren little
Тема Re: Emergency - Need assistance
Дата
Msg-id 1136233928.16094.33.camel@sharp
обсуждение исходный текст
Ответ на Re: Emergency - Need assistance  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Emergency - Need assistance  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-admin
Tom,
The extent of the messages I received from the command
pg_dump -Fc --table=casedocument -d tigrissave | pg_restore --verbose -d
tigris is listed below:

 pg_dump: SQL command failed
pg_dump: Error message from server: server closed the connection
unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
pg_restore: [custom archiver] could not read data block -- expected 1,
got 0
pg_restore: *** aborted because of error


I had removed all the files in pg_log prior to getting this error and no
new logfile was created.  I'm guessing I screwed up the logger when
removing all the files, but I assumed that when writing to the error
logs the backend would create a file if one did not exist.

I currently attempt to run the dump/restore with the zero_damaged_pages
turned on to see if the results yield something more useful.

About the beta version, this is temporary, hadn't really planned on
running production on our development box.  Haven't had any issues with
8.1beta for a few months and will be moving to 8.1.x as soon as some new
hardware arrives (about a week).

thanks

On Mon, 2006-01-02 at 15:10 -0500, Tom Lane wrote:
> warren little <warren.little@meridiascapital.com> writes:
> > I received the following error message when trying to copy a table from
> > one database to another on the same cluster:
>
> > pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
> > pg_restore: [custom archiver] could not read data block -- expected 1,
> > got 0
> > pg_restore: *** aborted because of error
>
> You seem to have omitted the messages that would indicate what's
> actually wrong; the above is all just subsidiary damage after whatever
> caused the FETCH to fail.
>
> > The table is about 25GB in size and takes a long time to dump/restore
> > and I'm running out of time to get the cluster back into production.
>
> > note running:
> > PostgreSQL 8.1beta4 on x86_64-unknown-linux-gnu, compiled by GCC gcc
> > (GCC) 3.4.4 20050721 (Red Hat 3.4.4-2)"
>
> You're running a production database on a beta release??
>
>             regards, tom lane
--
Warren Little
CTO
Meridias Capital Inc
ph 866.369.7763

В списке pgsql-admin по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Emergency - Need assistance
Следующее
От: Ben Kim
Дата:
Сообщение: Re: full data disk -- any chance of recovery