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

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

From: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Vadim Mikheev <vadim4o(at)email(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: AW: WAL does not recover gracefully from out-of-disk-space
Date: 2001-02-26 11:23:09
Message-ID: 11C1E6749A55D411A9670001FA687963368214@sdexcsrv1.f000.d0188.sd.spardat.at (view raw or flat)
Thread:
Lists: pgsql-hackers
> 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.

It would imho be great if this utility would also have a means to 
extend a logfile, that was not extended to the full 16Mb, and
revert the change that writes the whole file in the init phase.

Imho this write at logfile init time adds a substantial amount of IO,
that would better be avoided. If we really need this, it would imho 
be better to preallocate N logfiles and reuse them after checkpoint.

Andreas 

Responses

pgsql-hackers by date

Next:From: The Hermit HackerDate: 2001-02-26 12:37:35
Subject: Re: Re: [PATCHES] A patch for xlog.c
Previous:From: Jaume TeixiDate: 2001-02-26 10:48:12
Subject: Re: NOSUCCESS: m$ access -> psql howto ?

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