On Apr4, 2013, at 23:21 , Jeff Janes <jeff.janes@gmail.com> wrote:
> This brings up a pretty frightening possibility to me, unrelated to data checksums. If a bit gets twiddled in the
WALfile due to a hardware issue or a "cosmic ray", and then a crash happens, automatic recovery will stop early with
thefailed WAL checksum with an innocuous looking message. The system will start up but will be invisibly inconsistent,
andwill proceed to overwrite that portion of the WAL file which contains the old data (real data that would have been
necessaryto reconstruct, once the corruption is finally realized ) with an end-of-recovery checkpoint record and
continueto chew up real data from there.
Maybe we could scan forward to check whether a corrupted WAL record is followed by one or more valid ones with sensible
LSNs.If it is, chances are high that we haven't actually hit the end of the WAL. In that case, we could either log a
warning,or (better, probably) abort crash recovery. The user would then need to either restore the broken WAL segment
frombackup, or override the check by e.g. setting recovery_target_record="invalid_record". (The default would be
recovery_target_record="last_record".The name of the GUC tries to be consistent with existing recovery.conf settings,
eventhough it affects crash recovery, not archive recovery.)
Corruption of fields which we require to scan past the record would cause false negatives, i.e. no trigger an error
eventhough we do abort recovery mid-way through. There's a risk of false positives too, but they require quite specific
orderingsof writes and thus seem rather unlikely. (AFAICS, the OS would have to write some parts of record N followed
bythe whole of record N+1 and then crash to cause a false positive).
best regards,
Florian Pflug