Detailed description of changes:
r3588 | inaam | 2008-12-18 14:26:54 +0200 (Thu, 18 Dec 2008) | 8 lines
branches/5.1

It is a bug in unused code. If we don't calculate the hash value when
calculating the mutex number then two pages which map to same hash
value can get two different mutex numbers.

Approved by: Marko

Detailed description of changes:
r3412 | vasil | 2008-12-05 10:46:18 +0200 (Fri, 05 Dec 2008) | 7 lines
branches/5.1:

Add the traditional 2 spaces after the timestamp so the message does
not look like:

070223 13:26:01InnoDB: Warning: canno....

Detailed description of changes:
r3257 | inaam | 2008-11-24 22:06:50 +0200 (Mon, 24 Nov 2008) | 13 lines
branches/5.1 bug#40760

The config param innodb_thread_concurrency is dynamically set and is
read when a thread enters/exits innodb. If the value is changed between
the enter and exit time the behaviour becomes erratic.
The fix is not to use srv_thread_concurrency when exiting, instead use
the flag trx->declared_to_be_inside_innodb.

rb://57

Approved by: Marko

Detailed description of changes:

r2981 | marko | 2008-11-07 14:54:10 +0200 (Fri, 07 Nov 2008) | 6 lines
branches/5.1: row_mysql_store_col_in_innobase_format(): Correct a misleading
comment. In the UTF-8 encoding, ASCII takes 1 byte per character, while
the "latin1" character set (normally ISO-8859-1, but in MySQL it actually
refers to the Windows Code Page 1252 a.k.a. CP1252, WinLatin1)
takes 1 to 3 bytes (1 to 2 bytes for the ISO-8859-1 subset).

r3114 | calvin | 2008-11-14 20:31:48 +0200 (Fri, 14 Nov 2008) | 8 lines
branches/5.1: fix bug#40386: Not flushing query cache after truncate

ha_statistics.records can not be 0 unless the table is empty, set to
1 instead. The original problem of bug 29507 is fixed in the server.

Additional test was done with the fix of bug 29507 in the server.

Approved by: Heikki (on IM)

Detailed description of changes:
r2929 | marko | 2008-10-29 21:26:14 +0200 (Wed, 29 Oct 2008) | 13 lines
branches/5.1: dtype_get_sql_null_size(): return the correct storage
size of a SQL NULL column. (Bug #40369)

When MySQL Bug #20877 was fixed in r834, this function was
accidentally modified to return 0 or 1. Apparently, the only impact of
this bug is that fixed-length columns cannot be updated in-place from
or to SQL NULL, even in ROW_FORMAT=REDUNDANT.  After this fix,
fixed-length columns in ROW_FORMAT=REDUNDANT will have a constant
storage size as they should, no matter if NULL or non-NULL.  The bug
caused fixed-length NULL columns to occupy 1 byte.

rb://37 approved by Heikki over IM.

Detailed description of changes:
r2902 | vasil | 2008-10-28 12:10:25 +0200 (Tue, 28 Oct 2008) | 10 lines
branches/5.1:

Fix Bug#38189 innodb_stats_on_metadata missing

Make the variable innodb_stats_on_metadata visible to the users and
also settable at runtime. Previously it was only "visible" as a command
line startup option to mysqld.

Approved by:	Marko (https://svn.innodb.com/rb/r/36)

mysql-test/r/commit_1innodb.result:
  Increase commit count for row-based logging.

Bounds-checks and blocksize corrections were applied to user-input,
but constants in the server were trusted implicitly. If these values
did not actually meet the requirements, the user could not set change
a variable, then set it back to the (wonky) factory default or maximum
by explicitly specifying it (SET <var>=<value> vs SET <var>=DEFAULT).

Now checks also apply to the server's presets. Wonky values and maxima
get corrected at startup. Consequently all non-offsetted values the user
sees are valid, and users can set the variable to that exact value if
they so desire.

mysql-test/r/read_buffer_size_basic.result:
  test sets out of bounds value; we now throw a warning for this.
  This is a side-effect: before, the maximum was higher than the
  value we set here. The value was corrected to block-size, the
  maximum was not, hence the value was smaller than the maximum
  in this particular case. Now that we align the maxima at startup,
  the value in SET is larger than the (corrected) maximum, and we
  see a warning in this particular case. "This means we're doing it right."
mysql-test/r/read_rnd_buffer_size_basic.result:
  test sets out of bounds value; we now throw a warning for this.
  This is a side-effect: before, the maximum was higher than the
  value we set here. The value was corrected to block-size, the
  maximum was not, hence the value was smaller than the maximum
  in this particular case. Now that we align the maxima at startup,
  the value in SET is larger than the (corrected) maximum, and we
  see a warning in this particular case. "This means we're doing it right."
mysys/my_getopt.c:
  Do bounds-checking at start-up time so we'll catch and correct
  wonky default values and upper limits.
sql/mysqld.cc:
  If 0 is a legal value per the docs, not to mention the default, we shouldn't give 1 as
  the lower limit.
storage/innobase/handler/ha_innodb.cc:
  We are setting upper bounds here.
  ~0L gives -1. That is NOT what we want!

post push fix, added test found a valgrind warning

sql/sql_partition.cc:
  Bug#40972: Partition pruning can lead to crash for bad dates
  
  Fix for valgrind warning

Adding comments to some of the high-level functions in replication.

sql/log_event.h:
  Fixed some mistakes in comments.
sql/repl_failsafe.cc:
  Added comment for show_slave_hosts()
sql/slave.cc:
  Added comment for show_master_info(), handle_slave_[sql|io](), and next_event()
sql/sql_binlog.cc:
  Added @param comment.
sql/sql_lex.h:
  Added comment for st_lex_master_info.
sql/sql_repl.cc:
  Added comments for functions executing a statement:
      PURGE BINARY LOGS
      START SLAVE
      STOP SLAVE
      RESET SLAVE
      CHANGE MASTER
      RESET MASTER
      SHOW BINLOG EVENTS
      SHOW MASTER STATUS
      SHOW BINARY LOGS

When substituting system constant functions with a constant result
the server was not expecting that the function may return NULL.
Fixed by checking for NULL and returning Item_null (in the relevant
collation) if the result of the system constant function was NULL.

mysql-test/r/mysql.result:
  Bug #41437: test case
mysql-test/t/mysql.test:
  Bug #41437: test case.
  Relies on database() returning NULL if no database is
  selected.
sql/item_strfunc.cc:
  Bug #41437: Check for NULL result on evaluating the system
  constant function and return a constant NULL item.

The special TRUNCATE TABLE (DDL) transaction wasn't being properly
rolled back if a error occurred during row by row deletion. The
error can be caused by a foreign key restriction imposed by InnoDB
SE and would cause the server to erroneously issue a implicit
commit.

The solution is to rollback the transaction if a truncation via row
by row deletion fails, otherwise commit. All effects of a TRUNCATE 
ABLE operation are rolled back if a row by row deletion fails.

mysql-test/include/commit.inc:
  Truncate always starts a transaction and commits at the end.
  The commit at the end increases the count by two, one is the
  storage engine commit and the other is the binary log.
mysql-test/r/commit_1innodb.result:
  Update test case results.
mysql-test/r/innodb_mysql.result:
  Update test case results.
mysql-test/t/innodb_mysql.test:
  Add test case for Bug#37016
sql/sql_delete.cc:
  Move truncation using row by row deletion to its own function.
  If row by row deletion fails, rollback the transaction.
  
  Remove the meddling with disabling and enabling of autocommit
  as TRUNCATE transaction is now explicitly ended (committed
  or rolled back).

Problem: when the server reads a log_event from file, it should read
the post-header lengths from the format_description_log_event. Some
event types which currently have post-header length 0 did not do this,
and instead had a hard-coded zero length for the post-header. That
means the current server version will not be able to read future
versions of these events.
Fix: make the reader functions read the post-header.


sql/log_event.cc:
   - Made Format_description_log_event constructor initialize all
     post-header lengths explicitly, to make it easier to find them
     in the source code.
   - After this, it is no longer necessary to pass the MY_ZEROFILL
     flag to my_malloc. I removed the flag and added a sanity-check
     that will be executed only in debug-mode.
   - Made INTVAR, RAND, USER_VAR, and XID events skip post_header_len
     when reading from file.
sql/log_event.h:
  Added explicit defines for the lengths of all event types.

Passing dubious "year zero" in non-zero date (not "0000-00-00") could
lead to negative value for year internally, while variable was unsigned.
This led to Really Bad Things further down the line.

Now doing calculations with signed type for year internally.

mysql-test/r/date_formats.result:
  show that very early dates no longer break DATE_FORMAT(..., '%W')
mysql-test/t/date_formats.test:
  show that very early dates no longer break DATE_FORMAT(..., '%W')
sql-common/my_time.c:
  Allow negative years numbers internally while keeping the interface.
  otherwise if somebody passes year zero for whatever reason, we'll
  get an integer wrap-around that can lead to Really Bad Things further
  down the line. Note that amusingly, calcday_nr() already had signed
  output and calc_weekday() already had signed input, anyway.

The binlog_innodb test was sensitive to what tests ran before it.  Now run
FLUSH STATUS before performing operations that need to be checked.

sys_var_thd_ulong::update() was improperly casting an option value from
ulonglong to ulong before comparing it to the max allowed value.  On systems
where ulong and ulonglong are of different size, this caused values greater
than ULONG_MAX to wrap around (not be truncated to ULONG_MAX, which appears to
have been the intention of the original coder), and caused some checks to work
incorrectly.  This wasn't generally visible to the user, because later checks
would prevent the wrapped-around value from being used.  But it caused warning
messages to differ between 32- and 64-bit platforms.  Fix is to just remove the
cast.  Also added a DBUG_ASSERT to ensure that the value really is capped
properly before finally stuffing it into the ulong.

           locking type of temp table

The problem is that INSERT INTO .. SELECT FROM .. and CREATE
TABLE .. SELECT FROM a temporary table could inadvertently
overwrite the locking type of the temporary table. The lock
type of temporary tables should be a write lock by default.

The solution is to reset the lock type of temporary tables
back to its default value after they are used in a statement.

mysql-test/r/innodb_mysql.result:
  Add test case result for Bug#41348
mysql-test/r/temp_table.result:
  Add test case result for Bug#41348
mysql-test/t/innodb_mysql.test:
  Add test case for Bug#41348
mysql-test/t/temp_table.test:
  Add test case for Bug#41348
sql/sql_base.cc:
  Allow the lock type of temp tables to be overwritten now that
  the the value is being restored once the table is marked as
  free for re-use. This makes the behavior consistent with that
  of non-temporary tables and avoids confusion.

Added function to check for diff and return an error message if the utility is not present.
Previously, the way we did this didn't work on Windows, but did work on *Nix systems.