With current sources:
DEBUG: copy: line 629980, XLogWrite: new log file created - try to increase WAL_FILES
DEBUG: copy: line 694890, XLogWrite: new log file created - try to increase WAL_FILES
FATAL 2: copy: line 759383, ZeroFill(logfile 0 seg 13) failed: No space left on device
Server process (pid 3178) exited with status 512 at Fri Feb 23 21:53:19 2001
Terminating any active server processes...
Server processes were terminated at Fri Feb 23 21:53:19 2001
Reinitializing shared memory and semaphores
DEBUG: starting up
DEBUG: database system was interrupted at 2001-02-23 21:53:11
DEBUG: CheckPoint record at (0, 21075456)
DEBUG: Redo record at (0, 21075456); Undo record at (0, 0); Shutdown TRUE
DEBUG: NextTransactionId: 4296; NextOid: 145211
DEBUG: database system was not properly shut down; automatic recovery in progress...
DEBUG: redo starts at (0, 21075520)
The Data Base System is starting up
DEBUG: open(logfile 0 seg 0) failed: No such file or directory
TRAP: Failed Assertion("!(readOff > 0):", File: "xlog.c", Line: 1441)
!(readOff > 0) (0) [Bad file descriptor]
postmaster: Startup proc 3179 exited with status 134 - abort
Regardless of whether this particular behavior is fixable, this brings
up something that I think we *must* do before 7.1 release: create a
utility that blows away a corrupted logfile to allow the system to
restart with whatever is in the datafiles. Otherwise, there is no
recovery technique for WAL restart failures, short of initdb and
restore from last backup. I'd rather be able to get at data of
questionable up-to-dateness than not have any chance of recovery
at all.
regards, tom lane
