The MONTHNAME/DAYNAME functions
returns binary string, so the LOWER/UPPER functions
are not effective on the result of MONTHNAME/DAYNAME call.  
Character set of the MONTHNAME/DAYNAME function
result has been changed to connection character set.

- QUICK_INDEX_MERGE_SELECT deinitializes its rnd_pos() scan when it reaches EOF, but we 
  need to make the deinitialization in QUICK_INDEX_MERGE_SELECT destructor also. This is because
  certain execution strategies can stop scanning without reaching EOF, then then try to do a full
  table scan on this table. Failure to deinitialize caused the full scan to use (already empty) 
  table->sort and produce zero records.

resolve_stack_dump is not able to decode a stack trace produced
by glibc's backtrace() functions. The problem is that the stack
trace addresses are printed between brackets and the utility is
not able to ignore the brackets.

The solution is to modify resolve_stack_dump so it can recognize
stack trace addresses surrounded by brackets. e.g. [0xdeadbeef].

compiled --with-debug, due to bug 39828, "autoinc wraps around when offset and
increment > 1".  This change should be reverted when that bug is fixed (and a
a few other minor changes to the test as described in comments).

Static disabled plugins|engines and dynamic plugins which installed but disabled
are not visible in I_S PLUGINS|ENGINES tables because they are not stored into
global plugin array.
The fix: add such plugins|engines to plugin array with PLUGIN_IS_DISABLED status.
I_S.ENGINES 'Transactions', 'XA', 'Savepoints' fields have NULL value in this case.

            (server crash)

Altering a table with fulltext index[es] which use
pluggable fulltext parser may cause server crash
in debug builds.

The problem was that ALTER TABLE code wrongly assigned
fulltext parser name.

Also fixed that altering a table with fulltext index[es]
leave stale fulltext parser locks, which prevent
fulltext parsers from being uninstalled after
ALTER TABLE.

Detail:
- Choose the solution that was already in place (before last fix)
  for 6.0
- minor cleanup in comments

Related to operator precedence and associativity.
Make the expressions as explicit as possible.

Addition of hander function was_semi_consistent_read

Update test result file for binlog_innodb.result; the tested values (change in binlog_cache_use status variable) don't change, just the starting value is reduced.

resulted in a duplicate test case for bug 38231.

Bug #39830: Table autoinc value not updated on first insert.
Bug #35498: Cannot get table test/table1 auto-inccounter value in ::info
Bug #36411: Failed to read auto-increment value from storage engine" in 5.1.24 auto-inc

Detailed revision comments:

r2854 | sunny | 2008-10-23 08:30:32 +0300 (Thu, 23 Oct 2008) | 13 lines
branches/5.1: Backport changes from branches/zip r2725

Simplify the autoinc initialization code. This removes the
non-determinism related to reading the table's autoinc value for the first
time. This change has also reduced the sizeof dict_table_t by sizeof(ibool)
bytes because we don't need the dict_table_t::autoinc_inited field anymore.

rb://16

Bug #37788: InnoDB Plugin: AUTO_INCREMENT wrong for compressed tables

(Note, this bug is not only in the plugin, the overflow checks are relevant
for MySQL's InnoDB as well.)


Detailed revision comments:

r2852 | sunny | 2008-10-23 01:42:24 +0300 (Thu, 23 Oct 2008) | 9 lines
branches/5.1: Backport r2724 from branches/zip

Check column value against the col max value before updating the table's
global autoinc counter value. This is part of simplifying the AUTOINC
sub-system. We extract the type info from MySQL data structures at runtime.

Bug #40224: New AUTOINC changes mask reporting of deadlock/timeout errors


Detailed revision comments:

r2849 | sunny | 2008-10-22 12:01:18 +0300 (Wed, 22 Oct 2008) | 8 lines
branches/5.1: Return the actual error code encountered when allocating
a new autoinc value. The change in behavior (bug) was introduced in 5.1.22
when we introduced the new AUTOINC locking model.

rb://31

A follow-up to fix for bug #39438.  This moves some errro messages from the
server error log to the client, to make it easier for users (especially in
shared hosting environment) to get info about why their statement is failing.

Detailed revision comments:

r2832 | vasil | 2008-10-21 10:08:30 +0300 (Tue, 21 Oct 2008) | 10 lines
branches/5.1:

In ha_innobase::info():

Replace sql_print_warning() which prints to mysqld error log with
push_warning_printf() which sends the error message to the client.

Suggested by:	Marko, Sunny, Michael
Objected by:	Inaam

Detailed revision comments:

r2826 | vasil | 2008-10-20 14:09:01 +0300 (Mon, 20 Oct 2008) | 5 lines
branches/5.1:

Non-functional change: use a single tab instead of 12 spaces between
variable type and variable name.

Fix memory handling to avoid possible crash during error printout.  (Code
review, no associated bug.)


Detailed revision comments:

r2782 | marko | 2008-10-13 14:21:02 +0300 (Mon, 13 Oct 2008) | 5 lines
branches/5.1: Backport a fix from branches/zip r2763:

row_drop_database_for_mysql(): Postpone mem_free(table_name), so that
an error printout will not dereference freed memory.

Detailed revision comments:

r2744 | marko | 2008-10-09 10:53:09 +0300 (Thu, 09 Oct 2008) | 5 lines
branches/5.1: ha_innobase::delete_all_rows(): In response to a user asking
<http://forums.innodb.com/read.php?4,215,215> why DELETE FROM t is not
mapped to TRUNCATE TABLE t as it is in MyISAM, note in a comment that
DELETE is transactional while TRUNCATE is not.

Bug #39939: DROP TABLE/DISCARD TABLESPACE takes long time in buf_LRU_invalidate_tablespace()

Detailed revision comments:

r2742 | inaam | 2008-10-08 22:02:15 +0300 (Wed, 08 Oct 2008) | 11 lines
branches/5.1:

Improve implementation of buf_LRU_invalidate_tablespace by attempting
hash index drop in batches instead of doing it one by one.

Reviewed by: Heikki, Sunny, Marko
Approved by: Heikki

A follow-up fix for Bug 38839, which exposed a pre-existing bug in the
autoinc handling.

Detailed revision comments:

r2722 | sunny | 2008-10-04 02:48:04 +0300 (Sat, 04 Oct 2008) | 18 lines
branches/5.1: This bug has always existed but was masked by other errors. The
fix for bug# 38839 triggered this bug. When the offset and increment are > 1
we need to calculate the next value taking into consideration the two
variables. Previously we simply assumed they were 1 particularly offset was
never used. MySQL does its own calculation and that's probably why it seemed
to work in the past. We would return what we thought was the correct next
value and then MySQL would recalculate the actual value from that and return
it to the caller (e.g., handler::write_row()). Several new tests have been
added that try and catch some edge cases. The tests exposed a wrap around
error in MySQL next value calculation which was filed as bug 39828. The tests
will need to be updated once MySQL fix that bug.

One good side effect of this fix is that dict_table_t size has been
reduced by 8 bytes because we have moved the autoinc_increment field to
the row_prebuilt_t structure. See review-board for a detailed discussion.

rb://3

Send error message to the client when a rollback occurs when trying to get an
autoincrement value.  This is related to the fixes for Bug#36411 and
Bug#35498.

Detailed revision comments:

r2721 | sunny | 2008-10-04 02:08:23 +0300 (Sat, 04 Oct 2008) | 6 lines
branches/5.1: We need to send the messages to the client because
handler::get_auto_increment() doesn't allow a way to return the
specific error for why it failed.

rb://18