data and index files

It was possible if DATA/INDEX DIRECTORY is pointing to
symlinked MySQL data home directory.

Do not allow to drop data/index files implicitly symlinked
to data home directory. For such tables remove symlink only.

mysql-test/r/symlink.result:
  A test case for BUG#40980.
mysql-test/t/symlink.test:
  A test case for BUG#40980.
storage/myisam/mi_delete_table.c:
  Do not allow to drop data/index files implicitly symlinked
  to data home directory. For such tables remove symlink only.

When mysqlbinlog was given the --database=X flag, it always printed
'ROLLBACK TO', but the corresponding 'SAVEPOINT' statement was not
printed. The replicated filter(replicated-do/ignore-db) and binlog
filter (binlog-do/ignore-db) has the same problem. They are solved
in this patch together.

After this patch, We always check whether the query is 'SAVEPOINT'
statement or not. Because this is a literal check, 'SAVEPOINT' and
'ROLLBACK TO' statements are also binlogged in uppercase with no
any comments.

The binlog before this patch can be handled correctly except one case
that any comments are in front of the keywords. for example:
 /* bla bla */ SAVEPOINT a;
 /* bla bla */ ROLLBACK TO a;

The log event of 'CREATE EVENT' was being binlogged with garbage
at the end of the query if 'CREATE EVENT' is followed by another SQL statement
and they were executed as one command.
for example:
    DELIMITER |;
    CREATE EVENT e1 ON EVERY DAY DO SELECT 1; SELECT 'a';
    DELIMITER ;|
When binlogging 'CREATE EVENT', we always create a new statement with definer
and write it into the log event. The new statement is made from cpp_buf(preprocessed buffer).
which is not a c string(end with '\0'), but it is copied as a c string.

In this patch, cpp_buf is copied with its length.

Detailed revision comments:

r6884 | vdimov | 2010-03-26 13:05:03 +0200 (Fri, 26 Mar 2010) | 6 lines
branches/5.1:

Fix a non-determinism in innodb_bug38231.

Reported by:	Sergey Vojtovich <svoj@Sun.COM>

r6884 | vdimov | 2010-03-26 13:05:03 +0200 (Fri, 26 Mar 2010) | 6 lines
branches/5.1:

Fix a non-determinism in innodb_bug38231.

Reported by:	Sergey Vojtovich <svoj@Sun.COM>

The crash happens because of incorrect max_length calculation
in QUOTE function(due to overflow). max_length is set
to 0 and it leads to assert failure.
The fix is to cast expression result to
ulonglong variable and adjust it if the
result exceeds MAX_BLOB_WIDTH.


mysql-test/r/func_str.result:
  test case
mysql-test/t/func_str.test:
  test case
sql/item_strfunc.h:
  cast expression result to ulonglong variable and
  adjust it if the result exceeds MAX_BLOB_WIDTH.

There was no way to repair corrupt ARCHIVE data file,
when unrecoverable data loss is inevitable.

With this fix REPAIR ... EXTENDED attempts to restore
as much rows as possible, ignoring unrecoverable data.

Normal REPAIR is still able to repair meta-data file
only.

mysql-test/r/archive.result:
  A test case for BUG#46565.
mysql-test/std_data/bug46565.ARZ:
  A test case for BUG#46565.
mysql-test/std_data/bug46565.frm:
  A test case for BUG#46565.
mysql-test/t/archive.test:
  A test case for BUG#46565.
storage/archive/ha_archive.cc:
  Allow unrecoverable data loss when extended repair
  is requested.

by sort and fulltext keys.

Min value for myisam_sort_buffer_size is 4096.

Repairing MyISAM table with fulltext indexes and low
myisam_sort_buffer_size may crash the server.

Estimation of number of index entries was done incorrectly,
causing further assertion failure or server crash.

Docs note: min value for myisam_sort_buffer_size has been
changed from 4 to 4096.

mysql-test/r/fulltext.result:
  A test case for BUG#51866.
mysql-test/r/myisam.result:
  Min value for myisam_sort_buffer_size is 4096.
mysql-test/r/variables.result:
  Min value for myisam_sort_buffer_size is 4096.
mysql-test/suite/sys_vars/r/myisam_sort_buffer_size_basic_32.result:
  Min value for myisam_sort_buffer_size is 4096.
mysql-test/t/fulltext.test:
  A test case for BUG#51866.
sql/mysqld.cc:
  Min value for myisam_sort_buffer_size is 4096.
storage/myisam/mi_check.c:
  When estimating number of index entries for external
  fulltext parser, take into account that key_length may
  be bigger than myisam_sort_buffer_size. Reuse logic
  from _create_index_by_sort(): force MIN_SORT_BUFFER to
  be min value for myisam_sort_buffer_size.
  
  Another problem is that ftkey_nr has no other meaning
  than serial number of fulltext index starting with 1.
  We can't say if this key using built-in or external
  parser basing on it's value. In other words we always
  entered if-branch for external parser. At this point,
  the only way to check if we use default parser is to
  compare keyinfo::parser with &ft_default_parser.
storage/myisam/sort.c:
  Get rid of MIN_SORT_MEMORY, use MIN_SORT_BUFFER instead
  (defined in myisamdef.h, has the same value and purpose).

Invalid memory read if HANDLER ... READ NEXT is executed
after failed (e.g. empty table) HANDLER ... READ FIRST.

The problem was that we attempted to perform READ NEXT,
whereas there is no pivot available from failed READ FIRST.

With this fix READ NEXT after failed READ FIRST equals
to READ FIRST.

This bug affects MyISAM tables only.

mysql-test/r/gis-rtree.result:
  Restore a test case for BUG51357.
mysql-test/r/handler_myisam.result:
  A test case for BUG#51877.
mysql-test/t/gis-rtree.test:
  Restore a test case for BUG51357.
mysql-test/t/handler_myisam.test:
  A test case for BUG#51877.
storage/myisam/mi_rnext.c:
  "search first" failed. This means we have no pivot for
  "search next", or in other words MI_INFO::lastkey is
  likely uninitialized.
  
  Normally SQL layer would never request "search next" if
  "search first" failed. But HANDLER may do anything.
  
  As mi_rnext() without preceeding mi_rkey()/mi_rfirst()
  equals to mi_rfirst(), we must restore original state
  as if failing mi_rfirst() was not called.

When MyISAM writes newly created index page it may be
initialized partially. In other words some bytes of
sensible data and uninitialized tail of the page may
go into index file.

Under certain rare circumstances these hunks of memory
may contain data that would be otherwise inaccessible
to user, like passwords or data from other tables.

Fixed by initializing memory for temporary MyISAM key
buffer to '\0'.

No test case for this fix as it is heavily covered by
existing tests.

storage/myisam/mi_open.c:
  When creating new MI_INFO object, initialize MI_INFO::buff.
  This is done to ensure that we never write uninitialized
  memory hunks to index file.
storage/myisam/mi_page.c:
  No need to silence memory error detector anymore,
  page buffer is always initialized.
storage/myisam/mi_write.c:
  Fixed invalid memory read of 2 bytes. new_right_length
  is length of data on a page, including first 2 bytes
  that store this length itself. pos + k_length is pure
  data excluding these 2 bytes containing length.
storage/myisam/rt_index.c:
  To avoid uninitialized data write, create new page
  on info->buff, instead of locally allocated buffer.
  
  Note: second key block on info->buff is used here,
  because first block is used by called functions.
storage/myisam/rt_split.c:
  To avoid uninitialized data write, create new page
  on info->buff, instead of locally allocated buffer.

Detailed revision comments:

r6822 | vasil | 2010-03-15 10:17:31 +0200 (Mon, 15 Mar 2010) | 12 lines
branches/5.1:

Typecast to silence a compiler warning:

row/row0sel.c: 4548
        C4244: '=' : conversion from 'float' to 'ib_ulonglong', possible loss of data
row/row0sel.c: 4553
        C4244: '=' : conversion from 'double' to 'ib_ulonglong', possible loss of data

Reported by:	Jonas Oreland <Jonas.Oreland@Sun.COM>
Discussed with:	Sunny Bains <sunny.bains@oracle.com>

Detailed revision comments:

r6785 | vasil | 2010-03-10 09:04:38 +0200 (Wed, 10 Mar 2010) | 11 lines
branches/5.1:

Add the missing --reap statements in innodb_bug38231.test. Probably MySQL
enforced the presence of those recently and the test started failing like:

  main.innodb_bug38231                     [ fail ]
          Test ended at 2010-03-10 08:48:32
  
  CURRENT_TEST: main.innodb_bug38231
  mysqltest: At line 49: Cannot run query on connection between send and reap

r6788 | vasil | 2010-03-10 10:53:21 +0200 (Wed, 10 Mar 2010) | 8 lines
branches/5.1:

In innodb_bug38231.test: replace the fragile sleep 0.2 that depends on timing
with a more robust condition which waits for the TRUNCATE and LOCK commands
to appear in information_schema.processlist. This could also break if there
are other sessions executing the same SQL commands, but there are none during
the execution of the mysql test.

Detailed revision comments:

r6783 | jyang | 2010-03-09 17:54:14 +0200 (Tue, 09 Mar 2010) | 9 lines
branches/5.1: Fix bug #47621 "MySQL and InnoDB data dictionaries
will become out of sync when renaming columns". MySQL does not
provide new column name information to storage engine to
update the system table. To avoid column name mismatch, we shall
just request a table copy for now.

rb://246 approved by Marko.

Detailed revision comments:

r6780 | vasil | 2010-03-08 19:13:20 +0200 (Mon, 08 Mar 2010) | 4 lines
branches/5.1:

Whitespace fixup.

Detailed revision comments:

r6774 | calvin | 2010-03-03 23:56:10 +0200 (Wed, 03 Mar 2010) | 2 lines
branches/5.1: fix bug#51653: outdated reference to set-variable
Non functional change.

If the listed columns in the view definition of 
the table used in a 'INSERT .. SELECT ..'
statement mismatched, a debug assertion would
trigger in the cache invalidation code
following the failing statement.

Although the find_field_in_view() function
correctly generated ER_BAD_FIELD_ERROR during
setup_fields(), the error failed to propagate
further than handle_select(). This patch fixes
the issue by adding a check for the return
value.


mysql-test/r/query_cache_with_views.result:
  * added test for bug 46615
mysql-test/t/query_cache_with_views.test:
  * added test for bug 46615
sql/sql_parse.cc:
  * added check for handle_select() return code before attempting to invalidate the cache.

The crash happens because greedy_serach
can not determine best plan due to
wrong inner table dependences. These
dependences affects join table sorting
which performs before greedy_search starting.
In our case table which has real 'no dependences'
should be put on top of the list but it does not
happen as inner tables have no dependences as well.
The fix is to exclude RAND_TABLE_BIT mask from
condition which checks if table dependences
should be updated.


mysql-test/r/join.result:
  test result
mysql-test/t/join.test:
  test case
sql/sql_select.cc:
  RAND_TABLE_BIT mask should not be counted as it
  prevents update of inner table dependences.
  For example it might happen if RAND() function
  is used in JOIN ON clause.

  col equal to itself!

There's no need to copy the value of a field into itself.
While generally harmless (except for some performance penalties)
it may be dangerous when the copy code doesn't expect this.
Fixed by checking if the source field is the same as the destination
field before copying the data.
Note that we must preserve the order of assignment of the null 
flags (hence the null_value assignment addition).

The reason of the failure was apparent flaw in that a pointer to an uninitialized buffer was
passed to DBUG_PRINT of Protocol_text::store().

Fixed with splitting the print-out into two branches: 
one with length zero of the problematic arg and the rest.


sql/protocol.cc:
  correcting DBUG_PRINT to print out `from' with a care because one may be uninitialized in the caller.

            myisam tables

Queries following TRUNCATE of partitioned MyISAM table
may crash server if myisam_use_mmap is true.

Internally this is MyISAM bug, but limited to partitioned
tables, because MyISAM doesn't use ::delete_all_rows()
method for TRUNCATE, but goes via table recreate instead.

MyISAM didn't properly fall back to non-mmaped I/O after
mmap() failure. Was not repeatable on linux before, likely
because (quote from man mmap):
  SUSv3  specifies  that  mmap() should fail if length is 0.
  However, in kernels before 2.6.12, mmap() succeeded in
  this case: no mapping was created and the call returned
  addr. Since kernel 2.6.12, mmap() fails with the error
  EINVAL for this case.

mysql-test/r/partition.result:
  A test case for BUG#51868.
mysql-test/t/partition.test:
  A test case for BUG#51868.
storage/myisam/mi_delete_all.c:
  _mi_unmap_file() is compressed record format specific,
  which is read-only. As compressed MyISAM data files are
  read-only, we must never use _mi_unmap_file() in
  mi_delete_all_rows().
storage/myisam/mi_dynrec.c:
  Make myisam mmap code more durable to errors:
  - set file_read/file_write handlers if mmap succeeded;
  - reset file_read/file_write handlers on unmap.
storage/myisam/mi_extra.c:
  Moved file_read/file_write handlers initialization to
  mi_dynmap_file().
storage/myisam/myisamdef.h:
  Added mi_munmap_file() declaration.

Problem: caseup_multiply and casedn_multiply members      
were not initialized for a dynamic collation, so          
UPPER() and LOWER() functions returned empty strings.      
Fix: initializing the members properly.

Adding tests:
  mysql-test/r/ctype_ldml.result
  mysql-test/t/ctype_ldml.test

Applying the fix:
  mysys/charset.c

           for InnoDB

Patch to fix result files for the binlog suite under row-
based replication.

Bug #49910: Behavioural change in SELECT/WHERE on YEAR(4) data type                                  
(Original patch by Sinisa Milivojevic)

The YEAR(4) value of 2000 was equal to the "bad" YEAR(4) value of 0000.                              

The get_year_value() function has been modified to not adjust bad                                    
YEAR(4) value to 2000.


mysql-test/r/type_year.result:
  Test case for bug #49910.
mysql-test/t/type_year.test:
  Test case for bug #49910.
sql/item_cmpfunc.cc:
  Bug #49910: Behavioural change in SELECT/WHERE on YEAR(4) data type                                  
  
  The get_year_value() function has been modified to not adjust bad                                    
  YEAR(4) value to 2000.

comments to rpl_show_slave_running test are added to ease merging