
Sergei,
Hi, Andrei!
On Jun 12, andrei.elkin@pp.inet.fi wrote:
Did you already test that your commit actually fixes the issue?
Like I said, I did not try after we found it's NFS binlog. I've done it right now, but my attempt lasted minutes while in the user's case apart of anything specific they needed hours sometimes.
I don't understand, sorry. Were you able to repeat the user's error in your NFS tests?
Sorry, I wanted to say that I tried yesterday to reproduce the bug with few minutes testing against the base sources, and resultlessly. It could be that I needed to run for a lot more time, or only their NFS is prone to the bug.
I am committing a new patch which sustains the simulation test of the old one.
I don't quite like the test case. It may have nothing to do with the user's bug - we still don't know why it happens and we weren't able to repeat it, as far as I understand.
I could not reproduce. But let us see how the user will do. Personally I have 0% of doubt in that the fixes have made it.
If you just want to test that IO_CACHE doesn't read beyond end_of_file, it's a good thing to test, I agree. But it should be a unit test. So, please, remove this replication test and put a unit test for end_of_file into unittest/sql/mf_iocache-t.cc
I'm considering. Thanks! Andrei