Sorry,
forget the attachment.
On Mon, 2006-01-02 at 15:24 -0700, warren little wrote:
> The dump/restore failed even with the zero_damaged_pages=true.
> The the logfile (postgresql-2006-01-02_130023.log)
> did not have much in the way of useful info. I've attached the section
> of the logfile around the time of the crash. I cannot find any sign of
> a core file. Where might the core dump have landed?
>
> Regarding your comments about losing the evidence, the data I'm trying
> to load is in another database in the same cluster which I have no
> intention of purging until a can get the table moved to the new
> database.
>
> thanks
>
>
>
>
> On Mon, 2006-01-02 at 16:34 -0500, Tom Lane wrote:
> > 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly