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@xxxxxxxxxxxxxxxxxxx> 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
