Hello Monty,
We had had this discussion on Dec 19:
<guilhem> monty|movie: I realize: two days ago you wrote:
<guilhem> Dec 17 <monty> guilhem: Do you want to know the problem with the
first bug you found (a bit intersting, maybe...)
<guilhem> Dec 17 <monty> In UNDO for keys, I generated the key to be inserted.
This was the WHOLE key, including row number.
<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> Dec 17 <monty> Strange that our tests didn't cover this before...
<guilhem> Dec 17 <monty> Solution was two fold:
<guilhem> Dec 17 <monty> - For undo of key (ie, insert of key when replaying),
don't store row id
<guilhem> Dec 17 <monty> - On execeute of undo of row, store in memory and in
CRC the new row id
<guilhem> Dec 17 <monty> - When creating key for undo-key-delete, use stored
row id
<guilhem> Dec 17 <monty> - When reading clrs, always remmeber the row id in
case of undo-row-delete
<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> 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> 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?
<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> monty: ok, as you prefer.
<monty> So it's a simplification to go back, but will log more
<guilhem> monty: I leave it up to your judgement
<monty> I have thought about it
<monty> lets make it this way: If there is a single bug in that code, then I revert
<monty> ok ?
<guilhem> monty: Ok!
I was studying ma_blockrec.c and ma_key_recover.c today, and I have the
impression that afterwards, you removed the bugfix (made the
simplification). For example, in revision 1.22 of ma_delete.c,
function _ma_ck_delete(), you added (Dec 30):
/* Log also position to row */
key_length+= share->rec_reflength;
This is all fine with me, I just wonder if I didn't miss anything.
Thanks!
