> > You know - this is *core* assumption. If drive lies about this then
> > *nothing* will help you. Do you remember core rule of WAL?
> > "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?

Vadim

Fri, 12 Jan 2001 14:16:07 -0800
"Mikheev, Vadim" <vmikheev@SECTORBASE.COM>
RE: CRCs
On Fri, Jan 12, 2001 at 02:16:07PM -0800, Mikheev, Vadim wrote:
> > > You know - this is *core* assumption. If drive lies about this then
> > > *nothing* will help you. Do you remember core rule of WAL?
> > > "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.

To be more specific, if the blocks referenced in the log are partially 
written, their CRCs will (probably) be wrong.  If they are not 
physically written at all, their CRCs will be correct but will 
not match what is in the log.  In either case the user will know 
immediately that the database has been corrupted, and must fall 
back on a failover image or backup.

It would be no bad thing to include the CRC of the block referenced
wherever in the file format that a block reference lives.

Nathan Myers
ncm@zembu.com

Fri, 12 Jan 2001 14:54:45 -0800
ncm@zembu.com (Nathan Myers)
Re: CRCs
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.

AFAICS, disk-block CRCs do not guard against mishaps involving intended
writes.  They will help guard against data corruption that might creep
in due to outside factors, however.

			regards, tom lane

Fri, 12 Jan 2001 18:06:21 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: CRCs 
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.

> AFAICS, disk-block CRCs do not guard against mishaps involving intended
> writes.  They will help guard against data corruption that might creep
> in due to outside factors, however.

Right.  

Nathan Myers
ncm@zembu.com

Fri, 12 Jan 2001 15:48:30 -0800
ncm@zembu.com (Nathan Myers)
Re: CRCs
* 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."

Fri, 12 Jan 2001 16:10:36 -0800
Alfred Perlstein <bright@wintelcom.net>
Re: CRCs
On Fri, Jan 12, 2001 at 04:10:36PM -0800, Alfred Perlstein wrote:
> Nathan Myers <ncm@zembu.com> [010112 15:49] wrote:
> >
> > 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?

It's an OS and hardware configuration matter; you only get correct
WAL+fsync semantics if the underlying system is configured right.  
IDE disks are almost always configured wrong, to spoof benchmarks; 
SCSI disks sometimes are.

If they're configured wrong, then (now that we have a CRC in the 
log entry) in the event of a power outage the database might come 
back with recently-acknowledged transaction results discarded.
That's a lot better than a corrupt database, but it's not 
industrial-grade semantics.  (Use a UPS.)

Nathan Myers
ncm@zembu.com

Fri, 12 Jan 2001 16:43:10 -0800
ncm@zembu.com (Nathan Myers)
Re: CRCs
Nathan Myers wrote:
> 
> It wouldn't help you recover, but you would be able to report that
> you cannot recover.

While this could help decting hardware problems, you still won't be able
to detect some (many) memory errors because the CRC will be calculated
on the already corrupted data.

Of course there are other situations where CRC will not match and
appropriately logged is a reliable heads-up warning.

Bye!

-- 
 Daniele

Sat, 13 Jan 2001 01:41:53 +0000
Daniele Orlandi <daniele@orlandi.com>
Re: CRCs
>> AFAICS, disk-block CRCs do not guard against mishaps involving intended
>> writes.  They will help guard against data corruption that might creep
>> in due to outside factors, however.

> Right.  

Given that we seem to have agreed on that, I withdraw my complaint about
disk-block-CRC not being in there for 7.1.  I think we are still a ways
away from the point where externally-induced corruption is a major share
of our failure rate ;-).  7.2 or so will be time enough to add this
feature, and I'd really rather not force another initdb for 7.1.

			regards, tom lane

Fri, 12 Jan 2001 23:30:30 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: CRCs 
On Fri, Jan 12, 2001 at 11:30:30PM -0500, Tom Lane wrote:
> >> AFAICS, disk-block CRCs do not guard against mishaps involving intended
> >> writes.  They will help guard against data corruption that might creep
> >> in due to outside factors, however.
> 
> > Right.  
> 
> Given that we seem to have agreed on that, I withdraw my complaint about
> disk-block-CRC not being in there for 7.1.  I think we are still a ways
> away from the point where externally-induced corruption is a major share
> of our failure rate ;-).  7.2 or so will be time enough to add this
> feature, and I'd really rather not force another initdb for 7.1.

More to the point, putting CRCs on data blocks might have unintended
consequences for dump or vacuum processes.  7.1 is a monumental 
accomplishment even without corruption detection, and the sooner
the world has it, the better.

Nathan Myers
ncm@zembu.com

Sat, 13 Jan 2001 01:36:47 -0800
ncm@zembu.com (Nathan Myers)
Re: CRCs