RE: Crash during WAL recovery? - Mailing list pgsql-hackers

From Don Baccus
Subject RE: Crash during WAL recovery?
Date
Msg-id 3.0.1.32.20001121142111.022043b0@mail.pacifier.com
Whole thread Raw
In response to Crash during WAL recovery?  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
At 02:01 PM 11/21/00 -0800, Mikheev, Vadim wrote:
>> This snippet in xlog.c makes we wonder...
>> 
>>     else if (ControlFile->state == DB_IN_RECOVERY)
>>     {
>>         elog(LOG, "Data Base System was interrupted 
>> being in recovery at %s\n"
>>              "\tThis propably means that some data 
>> blocks are corrupted\n"
>>              "\tAnd you will have to use last 
>> backup for recovery",
>>              str_time(ControlFile->time));
>>     }
>> 
>> I thought this was going to be crash safe.
>
>WAL doesn't protect against disk block corruption what
>could be reason of crash (or elog(STOP)) during recovery
>in most cases. Apart from disk corruption recovery is
>(or should be -:)) crash safe.

Which is why we'll still need BAR tools later.

The WAL log can be used to recover from a crash if the database
itself isn't corrupted (disk corruption, whatever), but not
otherwise because it applies logged data to the database itself.

The WAL log doesn't include changes caused by renegade disk
controllers, etc :)

BAR tools will allow recovery via archives of WAL logs applied
to an archive of the database, to recreate the database in the
case where the existing database has been corrupted.

In Oracle parlance, "WAL" log == "REDO" log, and the BAR tool
builds "Archive" logs.

Uhhh...I think, anyway.



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.
 


pgsql-hackers by date:

Previous
From: "Mikheev, Vadim"
Date:
Subject: RE: Crash during WAL recovery?
Next
From: Peter Eisentraut
Date:
Subject: Re: [COMMITTERS] pgsql/contrib/pg_dumplo (README.pg_dumplo lo_export.c lo_import.c main.c pg_dumplo.h utils.c)