> > How? The scenario Vadim is pointing out is where the disk
> > drive writes a changed data block in advance of the WAL log
> > entry describing the change. Then power drops and the WAL
> > entry never gets made. At restart, how will you realize that
> > that data block now contains data you don't want? There's not
> > even a log entry telling you you need to look at it, much less
> > one that tells you what should be in it.
>
> OK. In that case, recent transactions that were acknowledged to user
> programs just disappear. The database isn't corrupt, but it doesn't
> contain what the user believes is in it.
Example.
1. Tuple was inserted into index.
2. Looking for free buffer bufmgr decides to write index block.
3. Following WAL core rule bufmgr first calls XLogFlush() to write and fsync log record related to index tuple
insertion.
4. *Beliving* that log record is on disk now (after successful fsync) bufmgr writes index block.
If log record was not really flushed on disk in 3. but on-disk image of
index block was updated in 4. and system crashed after this then after
restart recovery you'll have unlawful index tuple pointing to where?
Who knows! No guarantee that corresponding heap tuple was flushed on
disk.
Isn't database corrupted now?
Vadim