Re: CRCs
От | ncm@zembu.com (Nathan Myers) |
---|---|
Тема | Re: CRCs |
Дата | |
Msg-id | 20010112154830.X571@store.zembu.com обсуждение исходный текст |
Ответ на | Re: CRCs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: CRCs
Re: CRCs |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: