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

From Tom Lane
Subject Re: Emergency - Need assistance
Date
Msg-id 12399.1136237657@sss.pgh.pa.us
Whole thread Raw
In response to Re: Emergency - Need assistance  (warren little <warren.little@meridiascapital.com>)
Responses Re: Emergency - Need assistance  (warren little <warren.little@meridiascapital.com>)
List pgsql-admin
warren little <warren.little@meridiascapital.com> writes:
>  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

Hmm.  This could mean corrupted data files, but it's hard to be sure
without more info.

> 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.

The file *does* exist, there's just no directory link to it anymore :-(
You need to force a logfile rotation, which might be most easily done by
stopping and restarting the postmaster.

What you need to do is see the postmaster log entry about the backend
crash.  If it's dying on a signal (likely sig11 = SEGV) then inspecting
the core file might yield useful information.

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

That really ought to be the last resort not the first one, because it
will destroy not only data but most of the evidence about what went
wrong...

            regards, tom lane

pgsql-admin by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: full data disk -- any chance of recovery
Next
From: "Gregory S. Williamson"
Date:
Subject: Re: full data disk -- any chance of recovery