From: Michael Widenius
Date: April 25 2008 4:54pm
Subject: re: is rowid stored in UNDO_KEY_INSERT, in the end?
List-Archive: http://lists.mysql.com/maria/22
Message-Id: <18450.3288.159163.684067@narttu.mysql.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


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