sunny.bains@oracle.com-20100625081841-ppulnkjk1qlazh82

platform dependent diffs.

and clarifies the invariant in dict_table_get_on_id().
      
In Mar 2007 Marko observed a crash during recovery, the crash resulted from
an UNDO operation on a system table. His solution was to acquire an X lock on
the data dictionary, this in hindsight was an overkill. It is unclear what
caused the crash, current hypothesis is that it was a memory corruption.
      
The X lock results in performance issues by when undoing changes due to
rollback during normal operation on regular tables.
      
Why the change is safe:
======================
The InnoDB code has changed since the original X lock change was made. In the
new code we always lock the data dictionary in X mode during startup when
UNDOing operations on the system tables (this is a given). This ensures that
the crash Marko observed cannot happen as long as all transactions that update
the system tables follow the standard rules by setting the appropriate DICT_OP
flag when writing the log records when they make the changes.
      
If transactions violate the above mentioned rule then during recovery (at
startup) the rollback code (see trx0roll.c) will not acquire the X lock
and we will see the crash again.  This will however be a different bug.

(no changed files)

ha_innobase::create(): Add the local variable row_type = form->s->row_type.
Adjust it to ROW_TYPE_COMPRESSED when ROW_FORMAT is not specified or inherited
but KEY_BLOCK_SIZE is. Observe the inherited ROW_FORMAT even when it is not
explicitly specified.

innodb_bug54679.test: New test, to test the bug and to ensure that there are
no regressions. (The only difference in the test result without the patch
applied is that the first ALTER TABLE changes ROW_FORMAT to Compact.)

------------------------------------------------------------
revno: 3438
committer: Jimmy Yang <jimmy.yang@oracle.com>
branch nick: mysql-5.1-security
timestamp: Thu 2010-06-24 01:20:25 -0700
message:
  Fix Bug #54044 Create temporary tables and using innodb crashes.

to 5.1 plugin codeline.

rb://378, approved by Marko

out NULL type columns, and return without creating the table.

rb://378 approved by Marko

when renaming tables

Allocate the table name using ut_malloc() instead of table->heap because
the latter cannot be freed.

Adjust dict_sys->size calculations all over the code.

Change dict_table_t::name from const char* to char* because we need to
ut_malloc()/ut_free() it.

Reviewed by:	Inaam, Marko, Heikki (rb://384)
Approved by:	Heikki (rb://384)

ha_innobase::index_read(), ha_innobase::records_in_range(): Check that
the index is useable before invoking row_sel_convert_mysql_key_to_innobase().

This fix is based on a suggestion by Yasufumi Kinoshita.

In process of record search it is not taken into account
that inital quick->file->ref value could be inapplicable
to range interval. After proper row is found this value is
stored into the record buffer and later the record is
filtered out at condition evaluation stage.
The fix is store a refernce of found row to the handler ref field.

dict_check_tablespaces_and_store_max_id(): Initialize max_space_id
and fil_system->max_assigned_id from DICT_HDR_MAX_SPACE_ID.

fil_space_create(): Suppress the warning unless !recv_recovery_on
(do not complain while applying the redo log).

mysql_client_binlog_statement

Problem: server may read from unassigned memory performing
"wrong" BINLOG queries.

Fix: never read from unassigned memory.

1.0.9 has been released with MySQL 5.1.48.

rb://290, approved by Sunny

line exceeds the limit

Upmerge the fix from 5.0 to 5.1

           line exceeds the limit

The number and/or names of our files for the main test suite
(contents of "mysql-test/t/") now exceeds the command line
length limit on AIX.
Solve the problem by using separate "cp" commands for the
various file name extensions.

account for each merge run's start offset, so correct offsets are
paired up for multiple merge runs.

rb://377 approved by Marko

This is the fix for 5.5, where the behaviour on both installation
and upgrade is changed:
On installation, we do not start the server, to allow automated
installs (which happen in some indeterminate machine status).
If the server was stopped when the upgrade begins, we assume the
administrator is taking manual action, so we do not start the (new)
server at the end of the upgrade.
We still install the start/stop script, so it will be started on reboot.