List:Cluster« Previous MessageNext Message »
From:Magnus Svensson Date:July 28 2004 8:44am
Subject:Re: test results: build 1.1933
View as plain text  
On Tue, 2004-07-27 at 20:25, Joseph E. Sacco, Ph.D. wrote:
> System:
> * Powermac with dual g4 533MHz CPU's, 1 GB RAM, SCSi drives
> * Yellow Dog Linux 3.0.1
> * gcc-3.3.2
> * glibc-2.3.1-51a
> ===============================================================
> 
> Updated my BK tree today and ran the test suite:
> 
> 	mysql-4.1/mysql-test/mysql-test-run --force --with-ndbcluster
> 
> 
> Results:	
> 	Failed 4/278 tests, 98.56% successful
> 	* grant_cache
> 	* ndb_basic
> 	* ndb_lock
> 	* system_mysql_db_fix



> 
> =================================================================
> 
> The ndb test failures are not really failures. The row ordering from a
> command like
> 
> 	SELECT * FROM t1
> 
> is most likely hardware dependent [Is that correct???].


Yes that's correct. The hashing algorithm used for deciding in which
node the records should be stored is affected by the endian of your
machine.
To make the test output of ndb_basic and ndb_lock predictable I have
added an ORDER BY clause to these selects.

> 
> For example,
> 
> -------------------------------------------------------
> *** r/ndb_basic.result  2004-07-27 18:36:25.000000000 +0300
> --- r/ndb_basic.reject  2004-07-27 20:33:09.000000000 +0300
> ***************
> *** 31,38 ****
>   UPDATE t1 SET pk1=pk1 + 1;
>   SELECT * FROM t1;
>   pk1   attr1   attr2   attr3
> - 9412  9413    17      9413
>   3     1       NULL    9412
>   DELETE FROM t1;
>   SELECT * FROM t1;
>   pk1   attr1   attr2   attr3
> --- 31,38 ----
>   UPDATE t1 SET pk1=pk1 + 1;
>   SELECT * FROM t1;
>   pk1   attr1   attr2   attr3
>   3     1       NULL    9412
> + 9412  9413    17      9413
>   DELETE FROM t1;
>   SELECT * FROM t1;
>   pk1   attr1   attr2   attr3
> -------------------------------------------------------
> *** r/ndb_lock.result   2004-07-27 18:36:25.000000000 +0300
> --- r/ndb_lock.reject   2004-07-27 20:33:26.000000000 +0300
> ***************
> *** 19,25 ****
>   commit;
>   select * from t1;
>   x     y
> - 2     two
>   3     three
>   1     one
>   commit;
> --- 19,25 ----
>   commit;
>   select * from t1;
>   x     y
>   3     three
> + 2     two
>   1     one
>   commit;
> -------------------------------------------------------
> 
> If an 'ORDER BY" clause is added to the tests, the tests will pass.

Thanks!
> 
> 
> 
> The output from the other two tests that failed are shown below:
> -------------------------------------------------------
> *** r/grant_cache.result        2004-07-27 18:36:24.000000000 +0300
> --- r/grant_cache.reject        2004-07-27 20:24:12.000000000 +0300
> ***************
> *** 112,119 ****
>   Variable_name Value
>   Qcache_not_cached     1
>   show grants for current_user();
> ! Grants for @localhost
> ! GRANT USAGE ON *.* TO ''@'localhost'
>   select "user2";
>   user2
>   user2
> --- 112,119 ----
>   Variable_name Value
>   Qcache_not_cached     1
>   show grants for current_user();
> ! Grants for root@localhost
> ! GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION
>   select "user2";
>   user2
>   user2
> -------------------------------------------------------
> 

There is a bug filed for this, please see BUG#4678
http://bugs.mysql.com/bug.php?id=4678

> 
> I suspect that the result set for the grant_cache test is just wrong.
> Would someone please verify this one way or the other.
> 
> 
> --------------------------------------------------------
> system_mysql_db_fix            [ fail ]
>                                                                                      
>             
> Errors are (from
> /usr/local/src/MySQL/Cluster/mysql-4.1/mysql-test/var/log/mysqltest-time) :
> ERROR 1045: Access denied for user 'root'@'localhost' (using password:
> YES)
> cat: write error: Broken pipe
> /usr/local/src/MySQL/Cluster/mysql-4.1/client/.libs/mysqltest: At line
> 10: query 'show create table func' failed: 1146: Table 'test.func'
> doesn't exist
> (the last lines may be the most important ones)
>                                                                                      
>             
> Ending Tests
> Shutting-down MySQL daemon
>                                                                                      
>             
> Master shutdown finished
> Slave shutdown finished
> Resuming
> Tests                                                                                
>         ----------------------------------------------------------
> 
> I have looked at system_mysql_db_fix.test and am not sure how this test
> could ever run since it refers to some non-existent tables. I am not
> sure what is  causing the permission problem.

I'll let someone else answer this one. Could it be that the func table
has been added or dropped?

> 
> 
> -Joseph
> 
> -- 
> Joseph E. Sacco, Ph.D. <jsacco[at]earthlink[dot]net>
-- 
Magnus Svensson, Software Engineer
MySQL AB, www.mysql.com
Office: +46 709 164 491

Thread
test results: build 1.1933Ph.D. Joseph E. Sacco27 Jul
  • Re: test results: build 1.1933Magnus Svensson28 Jul