dict_table_get_format(index->table)

The REDUNDANT and COMPACT formats store a local 768-byte prefix of
each externally stored column. No row_ext cache is needed, but we
initialized one nevertheless. When the BLOB pointer was zero, we would
ignore the locally stored prefix as well. This triggered an assertion
failure in row_undo_mod_upd_exist_sec().

row_build(): Allow ext==NULL when a REDUNDANT or COMPACT table
contains externally stored columns.

row_undo_search_clust_to_pcur(), row_upd_store_row(): Invoke
row_build() with ext==NULL on REDUNDANT and COMPACT tables.

rb://382 approved by Jimmy Yang

columns

When the server crashes after a record stub has been inserted and
before all its off-page columns have been written, the record will
contain incomplete off-page columns after crash recovery. Such records
may only be accessed at the READ UNCOMMITTED isolation level or when
rolling back a recovered transaction in recv_recovery_rollback_active().
Skip these records at the READ UNCOMMITTED isolation level.

TODO: Add assertions for checking the above assumptions hold when an
incomplete BLOB is encountered.

btr_rec_copy_externally_stored_field(): Return NULL if the field is
incomplete.

row_prebuilt_t::templ_contains_blob: Clarify what "BLOB" means in this
context. Hint: MySQL BLOBs are not the same as InnoDB BLOBs.

row_sel_store_mysql_rec(): Return FALSE if not all columns could be
retrieved. Previously this function always returned TRUE.  Assert that
the record is not delete-marked.

row_sel_push_cache_row_for_mysql(): Return FALSE if not all columns
could be retrieved.

row_search_for_mysql(): Skip records containing incomplete off-page
columns. Assert that the transaction isolation level is READ
UNCOMMITTED.

rb://380 approved by Jimmy Yang

crash recovery"

rb://369 approved by Marko

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.)

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.

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).

1.0.9 has been released with MySQL 5.1.48.

rb://290, approved by Sunny

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

rb://377 approved by Marko

(innodb_mysql.result needs to be adjusted after this commit)

(InnoDB plugin branch)

mysql-test/suite/innodb_plugin/r/innodb_mysql.result:
  test case
mysql-test/suite/innodb_plugin/t/innodb_mysql.test:
  test case
storage/innodb_plugin/row/row0sel.c:
  init null bytes with default values as they might be
  left uninitialized in some cases and these uninited bytes
  might be copied into mysql record buffer that leads to
  valgrind warnings on next use of the buffer.

Valgrind warning happpens because of uninitialized null bytes.
In row_sel_push_cache_row_for_mysql() function we fill fetch cache
with necessary field values, row_sel_store_mysql_rec() is called
for this and leaves null bytes untouched.
Later row_sel_pop_cached_row_for_mysql() rewrites table record
buffer with uninited null bytes. We can see the problem from the
test case:
At 'SELECT...' we call row_sel_push...->row_sel_store...->row_sel_pop_cached...
chain which rewrites table->record[0] buffer with uninitialized null bytes.
When we call 'UPDATE...' statement, compare_record uses this buffer and
valgrind warning occurs.
The fix is to init null bytes with default values.


mysql-test/suite/innodb/r/innodb_mysql.result:
  test case
mysql-test/suite/innodb/t/innodb_mysql.test:
  test case
mysql-test/t/ps_3innodb.test:
  enable valgrind testing
storage/innobase/row/row0sel.c:
  init null bytes with default values as they might be
  left uninitialized in some cases and these uninited bytes
  might be copied into mysql record buffer that leads to
  valgrind warnings on next use of the buffer.

this before.