List:Maria Storage Engine« Previous MessageNext Message »
From:Michael Widenius Date:April 25 2008 4:54pm
Subject:re: is rowid stored in UNDO_KEY_INSERT, in the end?
View as plain text  

>>>>> "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.

is rowid stored in UNDO_KEY_INSERT, in the end?Guilhem Bichot24 Apr
  • re: is rowid stored in UNDO_KEY_INSERT, in the end?Michael Widenius25 Apr