From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: TODO list |
Date: | 2001-04-05 22:25:17 |
Message-ID: | 25376.986509517@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> writes:
>> If the reason that a block CRC isn't on the TODO list is that Vadim
>> objects, maybe we should hear some reasons why he objects? Maybe
>> the objections could be dealt with, and everyone satisfied.
> Unordered disk writes are covered by backing up modified blocks
> in log. It allows not only catch such writes, as would CRC do,
> but *avoid* them.
> So, for what CRC could be used? To catch disk damages?
> Disk has its own CRC for this.
Oh, I see. For anyone else who has trouble reading between the lines:
Blocks that have recently been written, but failed to make it down to
the disk platter intact, should be restorable from the WAL log. So we
do not need a block-level CRC to guard against partial writes.
A block-level CRC might be useful to guard against long-term data
lossage, but Vadim thinks that the disk's own CRCs ought to be
sufficient for that (and I can't say I disagree).
So the only real benefit of a block-level CRC would be to guard against
bits dropped in transit from the disk surface to someplace else, ie,
during read or during a "cp -r" type copy of the database to another
location. That's not a totally negligible risk, but is it worth the
overhead of updating and checking block CRCs? Seems dubious at best.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Henry B. Hotz | 2001-04-05 23:15:20 | Re: Call for platforms |
Previous Message | Nathan Myers | 2001-04-05 22:06:31 | Re: Re: TODO list |