Skip site navigation (1) Skip section navigation (2)

Re: WAL does not recover gracefully from out-of-disk-space

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Vadim Mikheev <vadim4o(at)email(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: WAL does not recover gracefully from out-of-disk-space
Date: 2001-02-24 08:41:13
Message-ID: 3A9773A9.73B7736B@tpf.co.jp (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> 
> 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.
> 

I've asked 2 or 3 times how to recover from recovery failure but
got no answer. We should some recipi for the failure before 7.1
release.

Regards,
Hiroshi Inoue

In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-02-24 12:41:14
Subject: pgaccess Japanese input capability patch
Previous:From: Bruce MomjianDate: 2001-02-24 06:36:00
Subject: Re: CommitDelay performance improvement

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group