Re: Emergency - Need assistance - Mailing list pgsql-admin

From warren little
Subject Re: Emergency - Need assistance
Date
Msg-id 1136233928.16094.33.camel@sharp
Whole thread Raw
In response to Re: Emergency - Need assistance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Emergency - Need assistance  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Emergency - Need assistance
Next
From: Ben Kim
Date:
Subject: Re: full data disk -- any chance of recovery