* Nathan Myers <ncm@zembu.com> [010112 15:49] wrote:
> On Fri, Jan 12, 2001 at 06:06:21PM -0500, Tom Lane wrote:
> > ncm@zembu.com (Nathan Myers) writes:
> > >>>>>> "Changes must be logged *before* changed data pages written".
> > >>>>>> If this rule will be broken then data files will be inconsistent
> > >>>>>> after crash recovery and you will not notice this, w/wo CRC in
> > >>>>>> data blocks.
> > >>>>
> > >>>> You can include the data blocks' CRCs in the log entries.
> > >>
> > >> How could it help?
> >
> > > It wouldn't help you recover, but you would be able to report that
> > > you cannot recover.
> >
> > 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.
>
> The only way I can think of to guard against that is to have a sequence
> number in each acknowledgement sent to users, and also reported when the
> database recovers. If users log their ACK numbers, they can be compared
> when the database comes back up.
>
> Obviously it's better to configure the disk so that it doesn't lie about
> what's been written.
I thought WAL+fsync wasn't supposed to allow this to happen?
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."