Hi!
>>>>> "Guilhem" == Guilhem Bichot <guilhem@stripped> writes:
Guilhem> Hello Monty,
Guilhem> We had had this discussion on Dec 19:
Guilhem> <guilhem> monty|movie: I realize: two days ago you wrote:
Guilhem> <guilhem> Dec 17 <monty> guilhem: Do you want to know the problem
> with the first bug you found (a bit intersting, maybe...)
Guilhem> <guilhem> Dec 17 <monty> In UNDO for keys, I generated the key to
> be inserted. This was the WHOLE key, including row number.
Guilhem> <guilhem> Dec 17 <monty> Problem was that when doing the undo, the
> undo for the row could put the row on a different position than the original and then the
> row number is of course different
Guilhem> <guilhem> Dec 17 <monty> Strange that our tests didn't cover this
> before...
Guilhem> <guilhem> Dec 17 <monty> Solution was two fold:
Guilhem> <guilhem> Dec 17 <monty> - For undo of key (ie, insert of key when
> replaying), don't store row id
Guilhem> <guilhem> Dec 17 <monty> - On execeute of undo of row, store in
> memory and in CRC the new row id
Guilhem> <guilhem> Dec 17 <monty> - When creating key for undo-key-delete,
> use stored row id
Guilhem> <guilhem> Dec 17 <monty> - When reading clrs, always remmeber the
> row id in case of undo-row-delete
Guilhem> <guilhem> Now, you are fixing that undo_row_delete puts the row back
> into the same place, so your big fix above becomes theoretically unneeded;
Guilhem> <guilhem> Without knowing much, I had the impression that this big fix
> was complex, possibly risky, especially I am not 100% sure it's recovery-safe (though I
> have no clear idea why);
Guilhem> <guilhem> hence my question: is it worth disabling your big fix of two
> days ago and going back to the simpler code (where UNDO contains the rowid inside the
> key)? Isn't it a nice simplification?
Guilhem> <monty> guilhem: the bug fix that I made for UNDO should still work. The
> benetif for this is that if you have 5 keys, I only store the pointer to the row onec
Guilhem> <guilhem> monty: ok, as you prefer.
Guilhem> <monty> So it's a simplification to go back, but will log more
Guilhem> <guilhem> monty: I leave it up to your judgement
Guilhem> <monty> I have thought about it
Guilhem> <monty> lets make it this way: If there is a single bug in that code,
> then I revert
Guilhem> <monty> ok ?
Guilhem> <guilhem> monty: Ok!
Guilhem> I was studying ma_blockrec.c and ma_key_recover.c today, and I have the
Guilhem> impression that afterwards, you removed the bugfix (made the
Guilhem> simplification). For example, in revision 1.22 of ma_delete.c,
Guilhem> function _ma_ck_delete(), you added (Dec 30):
Guilhem> /* Log also position to row */
Guilhem> key_length+= share->rec_reflength;
Guilhem> This is all fine with me, I just wonder if I didn't miss anything.
Guilhem> Thanks!
Yes, I should have removed the old bug fix completely.
Regards,
Monty
