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.

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

A follow-up to the previous patch, fix for Bug #39438.

r2720 | vasil | 2008-10-03 19:52:39 +0300 (Fri, 03 Oct 2008) | 8 lines
branches/5.1:

Print a warning if an attempt is made to get the free space for a table
whose .ibd file is missing or the tablespace has been discarded. This is a
followup to r2719.

Suggested by:	Inaam

Bug #39438: Testcase for Bug#39436 crashes on 5.1 in fil_space_get_latch


Detailed revision comments:

r2719 | vasil | 2008-10-03 18:17:28 +0300 (Fri, 03 Oct 2008) | 49 lines
branches/5.1:

Fix Bug#39438 Testcase for Bug#39436 crashes on 5.1 in fil_space_get_latch

In ha_innobase::info() - do not try to get the free space for a tablespace
which has been discarded with ALTER TABLE ... DISCARD TABLESPACE or if the
.ibd file is missing for some other reason.

ibd_file_missing and tablespace_discarded are manipulated only in
row_discard_tablespace_for_mysql() and in row_import_tablespace_for_mysql()
and the manipulation is protected/surrounded by
row_mysql_lock_data_dictionary()/row_mysql_unlock_data_dictionary() thus we
do the same in ha_innobase::info() when checking the values of those members
to avoid race conditions. I have tested the code-path with UNIV_DEBUG and
UNIV_SYNC_DEBUG.

rb://20

Reviewed by:	Inaam, Calvin
Approved by:	Heikki

branches/5.1:

Silence a compilation warning in UNIV_DEBUG.

Approved by:    Marko (via IM)

Bug#38231: Innodb crash in lock_reset_all_on_table() on TRUNCATE + LOCK / UNLOCK

branches/5.1:

Fix Bug#38231 Innodb crash in lock_reset_all_on_table() on TRUNCATE + LOCK / UNLOCK

In TRUNCATE TABLE and discard tablespace: do not remove table-level S
and X locks and do not assert on such locks not being wait locks.
Leave such locks alone.

Approved by:    Heikki (rb://14)

Bug #35498: Cannot get table test/table1 auto-inccounter value in ::info


Detailed revison comments:

r2702 | sunny | 2008-09-30 11:41:56 +0300 (Tue, 30 Sep 2008) | 13 lines
branches/5.1: Since handler::get_auto_increment() doesn't allow us
to return the cause of failure we have to inform MySQL using the
sql_print_warning() function to return the cause for autoinc failure.
Previously we simply printed the error code, this patch prints the
text string representing the following two error codes:

DB_LOCK_WAIT_TIMEOUT
DB_DEADLOCK.

Bug#35498 Cannot get table test/table1 auto-inccounter value in ::info

Approved by Marko.

Bug #39483: InnoDB hang on adaptive hash because of out of order ::open() call by MySQL


Detailed revision comments:

r2630 | inaam | 2008-09-16 19:11:26 +0300 (Tue, 16 Sep 2008) | 11 lines
branches/5.1   bug#39483 InnoDB hang on adaptive hash because of out
of order ::open() call by MySQL

Forward port of r2629

Under some conditions MySQL calls ::open with search_latch leading
to a deadlock as we try to acquire dict_sys->mutex inside ::open
breaking the latching order. The fix is to release search_latch.

Reviewed by: Heikki

Bug #38839: auto increment does not work properly with InnoDB after update


Detailed revision comments:

r2609 | sunny | 2008-08-24 01:19:05 +0300 (Sun, 24 Aug 2008) | 12 lines
branches/5.1: Fix for MySQL Bug#38839. Reset the statement level last
value field in prebuilt. This field tracks the last value in an autoincrement
interval. We use this value to check whether we need to update a table's
AUTOINC counter, if the value written to a table is less than this value
then we avoid updating the table's AUTOINC value in order to reduce
mutex contention. If it's not reset (e.g., after a DELETE statement) then
there is the possibility of missing updates to the table's AUTOINC counter
resulting in a subsequent duplicate row error message under certain 
conditions (see the test case for details).

Bug #38839 - auto increment does not work properly with InnoDB after update