hi!
>>>>> "Yuri" == Yuri Dario <mc6530@stripped> writes:
Yuri> Hi Monty,
Yuri> 1) alter_table.test: check table reports
>> Very strange; The message is ok, but I don't understand why this is
>> different from the standard one...
Yuri> could be related to buffered disk writes?
No..
Yuri> 2) func_test: at line 16
>> Are you using our regexp library or a one that is in OS/2 ?
Yuri> were using mysql regex, and I fixed it using isxxx() macros from
Yuri> m_ctype.h; seems that standard macros (ctype.h) are a little different.
Strange; The macros in m_ctype.h should be ok.
Yuri> 3) merge: 'select * from t3 order by a desc' is failing, reporting
>> No comments; I would need a trace to give any hints about this.
Yuri> ok, I can do it, but 'select * from t3' gives the correct result: I
Yuri> suspect a bug only in ordering: who is doing such task?
The order should be the same on all systems. I really need a trace to
be able to comment.
Yuri> 5) show_check.test: same as alter_table, plus
>> Did you run the test 'standalone' or with 'mysql-test-run --force' ?
Yuri> happens in both modes.
Yuri> 6) status.test: different locking count
>> This is strange; If you are using just one client, you should never
>> get table_locks_waited.
Yuri> status.test has two connections, and my problem is that I don't have a
Yuri> waited lock :-)
The waited lock counter should only be incremented when MySQL tries to
do a table lock and the table is already locked.
If you have a working debugger, this should be easy to find.
Just put a breakpoint in mysys/thr_lock.c at:
statistic_increment(locks_waited, &THR_LOCK_lock);
and run the test.
Regards,
Monty