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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] so that your
> message can get through to the mailing list cleanly
@ 2006-01-02 15:02:02 MST:LOG: autovacuum: processing database "tigris"
@ 2006-01-02 15:03:01 MST:LOG: server process (PID 28772) was terminated by
signal 11
@ 2006-01-02 15:03:01 MST:LOG: terminating any other active server processes
[EMAIL PROTECTED] 2006-01-02 15:03:01 MST:WARNING: terminating connection
because of crash of another server process
[EMAIL PROTECTED] 2006-01-02 15:03:01 MST:DETAIL: The postmaster has commanded
this server process to roll back the current transaction and exit, because
another server process exited abnormally and possibly corrupted shared memory.
[EMAIL PROTECTED] 2006-01-02 15:03:01 MST:HINT: In a moment you should be able
to reconnect to the database and repeat your command.
192.168.19.129(50732)@192.168.19.129 2006-01-02 15:03:01 MST:WARNING:
terminating connection because of crash of another server process
192.168.19.129(50732)@192.168.19.129 2006-01-02 15:03:01 MST:DETAIL: The
postmaster has commanded this server process to roll back the current
transaction and exit, because another server process exited abnormally and
possibly corrupted shared memory.
192.168.19.129(50732)@192.168.19.129 2006-01-02 15:03:01 MST:HINT: In a moment
you should be able to reconnect to the database and repeat your command.
192.168.19.129(50730)@192.168.19.129 2006-01-02 15:03:01 MST:WARNING:
terminating connection because of crash of another server process
192.168.19.129(50730)@192.168.19.129 2006-01-02 15:03:01 MST:DETAIL: The
postmaster has commanded this server process to roll back the current
transaction and exit, because another server process exited abnormally and
possibly corrupted shared memory.
192.168.19.129(50730)@192.168.19.129 2006-01-02 15:03:01 MST:HINT: In a moment
you should be able to reconnect to the database and repeat your command.
192.168.19.129(50731)@192.168.19.129 2006-01-02 15:03:01 MST:WARNING:
terminating connection because of crash of another server process
192.168.19.129(50731)@192.168.19.129 2006-01-02 15:03:01 MST:DETAIL: The
postmaster has commanded this server process to roll back the current
transaction and exit, because another server process exited abnormally and
possibly corrupted shared memory.
192.168.19.129(50731)@192.168.19.129 2006-01-02 15:03:01 MST:HINT: In a moment
you should be able to reconnect to the database and repeat your command.
@ 2006-01-02 15:03:01 MST:LOG: all server processes terminated; reinitializing
@ 2006-01-02 15:03:01 MST:LOG: database system was interrupted at 2006-01-02
15:02:47 MST
@ 2006-01-02 15:03:01 MST:LOG: checkpoint record is at 37/D60F93A8
@ 2006-01-02 15:03:01 MST:LOG: redo record is at 37/D6008018; undo record is
at 0/0; shutdown FALSE
@ 2006-01-02 15:03:01 MST:LOG: next transaction ID: 32196280; next OID:
102041945
@ 2006-01-02 15:03:01 MST:LOG: next MultiXactId: 41; next MultiXactOffset: 93
@ 2006-01-02 15:03:01 MST:LOG: database system was not properly shut down;
automatic recovery in progress
@ 2006-01-02 15:03:01 MST:LOG: redo starts at 37/D6008018
@ 2006-01-02 15:03:01 MST:LOG: record with zero length at 37/D60F93F8
@ 2006-01-02 15:03:01 MST:LOG: redo done at 37/D60F93A8
@ 2006-01-02 15:03:02 MST:LOG: database system is ready
@ 2006-01-02 15:03:02 MST:LOG: transaction ID wrap limit is 1087118600,
limited by database "cert"
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
