When mysqldadmin is run with sleep and count options,
it goes into an infinite loop and keeps executing the
specified command.

This happened because the statement, responsible for
decrementing the count value, was missing.

Fixed by adding a statement which will decrement the
count value for each iteration.

It is a backported patch.

Backport to 5.0.

/*![:version:] Query Code */, where [:version:] is a sequence of 5 
digits representing the mysql server version(e.g /*!50200 ... */),
is a special comment that the query in it can be executed on those 
servers whose versions are larger than the version appearing in the 
comment. It leads to a security issue when slave's version is larger 
than master's. A malicious user can improve his privileges on slaves. 
Because slave SQL thread is running with SUPER privileges, so it can
execute queries that he/she does not have privileges on master.
      
This bug is fixed with the logic below: 
- To replace '!' with ' ' in the magic comments which are not applied on
  master. So they become common comments and will not be applied on slave.
      
- Example:
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /*!99999 ,(3)*/
   will be binlogged as
  'INSERT INTO t1 VALUES (1) /*!10000, (2)*/ /* 99999 ,(3)*/

        For all the boolean system variables we now issue warnings if the
        value wasn't recognized. Before that we just silently set them
        to FALSE in this case.

per-file comments:
  mysys/my_getopt.c
Bug #46393 If for slow_query_log a string is entered it does not complain.
        warning issued if no documented value was specified.

        IA64 and some other arcitectures use different float rounding mode and
        i find no decent way to make it consistent.
        So the test changed to be insensitive to this.

per-file messages:
  mysql-test/t/gis.test
Bug#52208      gis fails on some platforms (Solaris, HP-UX, Linux)
        --replace_result added

When mysqldump tries to dump information in xml format,
the result does not contain field level comments.

In order to retrieve various informations for a field/column,
mysqldump currently uses 'show fields from <tab>' statement.
The attributes returned by the statement lacks the information
regarding field comments.

Fixed by changing the query to one that probes I_S to retrieve
required field informations, including the field comment.

The test passes on MacOSX. removing it from the experimental list.

Backported the fix to 5.1.
Problem: the auxiliary test files rpl_start_server.inc and rpl_stop_server.inc
write a file that is later read by mtr. The bug was that the file was written
with platform-dependent newline terminators, i.e., \r\n on windows, whereas mtr
only understands \n.
Fix: write the file so that it uses \n on all platforms.

Fix: copy my_decimal by value, to avoid dangling pointers.

Bug#58525: separate string and numbers for comparing

Added comments to rpl_show_relaylog_events as requested by 
reviewer.

Refactoring effort on test case rpl_show_relaylog_events
requested by reviewers.

            null from mysql_store_result.

mysqlslap segfaults at a point when it tries to fetch rows from
the result set.

Under some circumstances, mysql_store_result can return 'NULL',
even after query execution (mysql_query) succeeds, and eventually
a segfault might occur if same unchecked return value is passed
to mysql_fetch_row.

Fixed by adding a check on mysql_store_result's return value.

other crashes

Some string manipulating SQL functions use a shared string object intended to
contain an immutable empty string. This object was used by the SQL function
SUBSTRING_INDEX() to return an empty string when one argument was of the wrong
datatype. If the string object was then modified by the sql function INSERT(),
undefined behavior ensued.

Fixed by instead modifying the string object representing the function's
result value whenever string manipulating SQL functions return an empty
string.

Relevant code has also been documented.

The problem from a user point of view was that on Solaris the
time related functions (e.g. NOW(), SYSDATE(), etc) would always
return a fixed time.

This bug was happening due to a logic in the time retrieving
wrapper function which would only call the time() function every
half second. This interval between calls would be calculated
using the gethrtime() and the logic relied on the fact that time
returned by it is monotonic.

Unfortunately, due to bugs in the gethrtime() implementation,
there are some cases where the time returned by it can drift
(See Solaris bug id 6600939), potentially causing the interval
calculation logic to fail.

Since newer versions of Solaris (10+) have alleviated the
performance degradation associated with time(2), the solution is
to simply directly rely on time() at each invocation.

This simplification has an upside that it allows us to eliminate
a lock which was used to control access to the variables used
to track the half second interval, thus improving the overall
scalability of timekeeping related functions (e.g. NOW()).

Benchmarks runs have shown no significant degradation associated
with this change. With this, there are actually improvements in
performance for cases involving many connections.

In summary, the changes introduced by this patch are:

a) my_time() and my_micro_time_and_time() no longer use gethrtime().
   Instead, time() and gettimeofdate() are used correspondingly.

b) my_micro_time() is changed to not use gethrtime() so as to
   have the same time source as my_micro_time_and_time().
   There shouldn't be any performance impact from this change
   since this function is used only a few times during statement
   execution and, on Solaris, gettimeofday() shows acceptable
   performance.

Fixed incorrect checks in join_read_const_table() for when to 
accept a non-existing, or empty const-row as a part of the const'ified 
set of tables.
      
Intention of this test is to only accept NULL-rows if this table is outer joined
into the resultset. (In case of an inner-join we can conclude at this point that 
resultset will be empty, end we want to return 'error' to signal this.)
      
Initially 'maybe_null' is set to the same value as 'outer_join' in 
setup_table_map(), mysql_priv.h ~line 2424. Later simplify_joins() will
attemp to replace outer joins by inner join whenever possible. This
will cause 'outer_join' to be updated. However, 'maybe_null' is *not* updated
to reflect this rewrite as this field is used to currectly set the 'nullability'
property for the columns in the resultset.
      
We should therefore change join_read_const_table() to check the 'outer_join'
property instead of 'maybe_null', as this correctly reflect the nullability of
the *execution plan* (not *resultset*).

An incorrect 'table_map' containing both the table itself, 
and possible any outer-refs if this was the last table in 
the subquery, was presented to make_cond_for_table().
      
As a pushed condition is only able to refer column from the table
the condition is pushed to, nothing else than columns from the
table itself (tab->table->map) may be refered in the pushed condition
constructed by 'push_cond= make_cond_for_table()'. 
      
Also fix a minor 'copy and paste' bug in a comment 
inside make_cond_for_table().

No testcase is possible on mainbranch as the NDB engine is not available (yet)
on mysql >= 5.5

Item_equal::val_int() checked for NULL-values by checking Item::null_value
*before* the respective ::store_value() and ::cmp(Item*) metods where called.

As Item::null_value is set by these metods, the value of 'null_value' 
is not valid until *after* ::store_value() or ::cmp() has
been called for the Item object.
      
Fix is to swap order of ::store_value()/::cmp() and checking of Item::null_value.
This pattern is widely used other places inside item_cmpfunc.cc .

      
The test case fails with out of memory while updating a table
with several multi-megabytes sized rows. This can probably be too
exhausting for PB2 env.
      
The quick fix here is to reduce the size of the biggest
row (256MB) so that it becomes a little smaller (64MB).

The test started failing on the same day patch for BUG 49978 was
pushed. BUG 49978 changed part of the replication testing
infrastructure in mysql-test-run. This caused the test to fail
sporadically with result differences on relay log file
names. When the test fails the relay-log filenames are shifted by
one, eg:

-show relaylog events in 'slave-relay-bin.000002' from <binlog_start>;
+show relaylog events in 'slave-relay-bin.000003' from <binlog_start>;

The problem was caused by a bad cleanup when using the include
files:

  - include/setup_fake_relay_log.inc
  - include/cleanup_fake_relay_log.inc

Which would leave a spurious relay-log file around (not listed in
slave-relay-bin.index), causing the server to shift the name of
the relay logs by one, even if cleaning up with RESET SLAVE.

We fix this by removing the relay-log file when it is not needed
anymore, ie at setup time and after recreating the fake relay-log
index.

Additionally, to make the affected test more resilient, we
deployed a call to rpl_reset.inc (which resets both master and
slave, including log files) before actually running the test
case.

Finally, appart from the reported bug, we also fix: (a) an
unrelated issue with the failing test itself - in some cases, the
test was not setting the log file name to use when it should; 
(b) one typo.