bzr push into mysql-5.1 branch (nuno.carvalho:3721 to 3722) WL#6236

[Nuno Carvalho]

 3722 Nuno Carvalho	2012-04-18
      WL#6236: Allow SHOW MASTER LOGS and SHOW BINARY LOGS with REPLICATION CLIENT
      
      Currently SHOW MASTER LOGS and SHOW BINARY LOGS require the SUPER
      privilege. Monitoring tools (such as MEM) often want to check this 
      output - for instance MEM generates the SUM of the sizes of the logs 
      reported here, and puts that in the Replication overview within the MEM
      Dashboard.
      However, because of the SUPER requirement, these tools often have an 
      account that holds open the connection whilst monitoring, and can lock
      out administrators when the server gets overloaded and reaches
      max_connections - there is already another SUPER privileged account
      connected, the "monitor". 
      
      As SHOW MASTER STATUS, and all other replication related statements,
      return with either REPLICATION CLIENT or SUPER privileges, this worklog 
      is to make SHOW MASTER LOGS and SHOW BINARY LOGS be consistent with this
      as well, and allow both of these commands with either SUPER or 
      REPLICATION CLIENT. 
      This allows monitoring tools to not require a SUPER privilege any more,
      so is safer in overloaded situations, as well as being more secure, as 
      lighter privileges can be given to users of such tools or scripts.

    modified:
      mysql-test/suite/binlog/r/binlog_grant.result
      mysql-test/suite/binlog/t/binlog_grant.test
      sql/sql_parse.cc
 3721 Chaithra Gopalareddy	2012-04-18
      Bug#12713907:STRANGE OPTIMIZE & WRONG RESULT UNDER
                         ORDER BY COUNT(*) LIMIT.
      
      PROBLEM:
      With respect to problem in the bug description, we
      exhibit different behaviors for the two tables
      presented, because innodb statistics (rec_per_key
      in this case) are updated for the first table
      and not so for the second one. As a result the
      query plan gets changed in test_if_skip_sort_order
      to use 'index' scan. Hence the difference in the
      explain output. (NOTE: We can reproduce the problem
      with first table by reducing the number of tuples
      and changing the table structure)
      
      The varied output w.r.t the query on the second table
      is because of the result in the query plan change.
      When a query plan is changed to use 'index' scan,
      after the call to test_if_skip_sort_order, we set
      keyread to TRUE immedietly. If for some reason
      we drop this index scan for a filesort later on,
      we fetch only the keys not the entire tuple.
      As a result we would see junk values in the result set.
      
      Following is the code flow:
      
      Call test_if_skip_sort_order
      -Choose an index to give sorted output
      -If this is a covering index, set_keyread to TRUE
      -Set the scan to INDEX scan
      
      Call test_if_skip_sort_order second time
      -Index is not chosen (note that we do not pass the
      actual limit value second time. Hence we do not choose
      index scan second time which in itself is a bug fixed
      in 5.6 with WL#5558)
      -goto filesort
      
      Call filesort
      -Create quick range on a different index
      -Since keyread is set to TRUE, we fetch only the columns of
      the index
      -results in the required columns are not fetched
      
      FIX:
      Remove the call to set_keyread(TRUE) from
      test_if_skip_sort_order. The access function which is
      'join_read_first' or 'join_read_last' calls set_keyread anyways.
     @ mysql-test/r/func_group_innodb.result
        Added test result for Bug#12713907
     @ mysql-test/t/func_group_innodb.test
        Added test case for Bug#12713907
     @ sql/sql_select.cc
        Remove the call to set_keyread as we do it from access
        functions 'join_read_first' and 'join_read_last'

    modified:
      mysql-test/r/func_group_innodb.result
      mysql-test/t/func_group_innodb.test
      sql/sql_select.cc
=== modified file 'mysql-test/suite/binlog/r/binlog_grant.result'
--- a/mysql-test/suite/binlog/r/binlog_grant.result	2008-09-09 10:19:31 +0000
+++ b/mysql-test/suite/binlog/r/binlog_grant.result	2012-04-18 09:08:01 +0000
@@ -26,3 +26,7 @@ ERROR 42000: Access denied; you need the
 **** Clean up ****
 set global binlog_format = @saved_binlog_format;
 drop user mysqltest_1@localhost;
+GRANT REPLICATION CLIENT ON *.* TO 'mysqltest_1'@'localhost';
+SHOW MASTER LOGS;
+SHOW BINARY LOGS;
+DROP USER 'mysqltest_1'@'localhost';

=== modified file 'mysql-test/suite/binlog/t/binlog_grant.test'
--- a/mysql-test/suite/binlog/t/binlog_grant.test	2008-09-09 10:19:31 +0000
+++ b/mysql-test/suite/binlog/t/binlog_grant.test	2012-04-18 09:08:01 +0000
@@ -58,3 +58,22 @@ disconnect root;
 connection default;
 set global binlog_format = @saved_binlog_format;
 drop user mysqltest_1@localhost;
+
+
+# Testing if REPLICATION CLIENT privilege is enough to execute
+# SHOW MASTER LOGS and SHOW BINARY.
+GRANT REPLICATION CLIENT ON *.* TO 'mysqltest_1'@'localhost';
+--connect(rpl,localhost,mysqltest_1,,)
+
+--connection rpl
+# We are only interested if the following commands succeed and not on
+# their output.
+--disable_result_log
+SHOW MASTER LOGS;
+SHOW BINARY LOGS;
+--enable_result_log
+
+# clean up
+--disconnect rpl
+connection default;
+DROP USER 'mysqltest_1'@'localhost';

=== modified file 'sql/sql_parse.cc'
--- a/sql/sql_parse.cc	2012-02-19 03:18:49 +0000
+++ b/sql/sql_parse.cc	2012-04-18 09:08:01 +0000
@@ -3057,7 +3057,7 @@ end_with_restore_list:
     goto error;
 #else
     {
-      if (check_global_access(thd, SUPER_ACL))
+      if (check_global_access(thd, SUPER_ACL | REPL_CLIENT_ACL))
 	goto error;
       res = show_binlogs(thd);
       break;

No bundle (reason: useless for push emails).