The server crashes when receiving a COM_BINLOG_DUMP command with a position of 0 or
larger than the file size.
The execution proceeds to an error block having the last read replication coordinates 
pointer be NULL and its dereferencing crashed the server.

Fixed with making "public" previously used only for heartbeat coordinates.

Relax a bogus debug assertion.
Approved by Jimmy Yang on IM.

Add option to set project name for Mac/Windows.

  and cryptic error 1126 message

The problem was that dlopen() related code was using just a subset 
of the path normalization routines used in other places.
Fixed the expansion of the pre-dlopen() behavior for plugins and UDFs
to use a platform-dependent consistent encoding of the paths.
Fixed the error dlopen() error handling to take the correct error message
and strip off the trailing newline character(s).
Fixed tests to do a platform independent replace of directories and to 
account for the traling slash.

Test extra/rpl_tests/rpl_extra_col_master.test (used by
rpl_extra_col_master_*) ends with the active connection pointing to the
slave. Thus, the two last tests never succeed in changing the binlog
format of the master away from 'row'. With correct active connection
(master) tests fail for binlog 'statement' and 'mixed' formats.

Tests rpl_extra_col_master_* only run when binary log format is
row.  Statement and mix replication do not make sense in this
tests since it will try to execute statements on columns that do
not exist.  This fix is basically a backport from mysql-5.5, see
changes done as part of BUG 39934.

When mode==BUF_KEEP_OLD, buffered inserts are being merged to the page.
It is possible that a read request for a page was pending while the page
was freed in DROP INDEX or DROP TABLE. In these cases, it is OK (although
useless) to merge the buffered changes to the freed page.

ISSUES WITH COPYING PARTITIONED INNODB TABLES FROM LINUX TO WINDOWS

This problem was already fixed in mysql-trunk as part of bug #11755924.  I am 
backporting the fix to mysql-5.1.  

merge of Nirbhay's AIX compilation fix for 5.1.61

Fixing the 5.5 part (the 5.6 part will go in a separate commit soon).

Problem:
  Item_direct_ref::get_date() incorrectly calculated its "null_value",
  which made UNIX_TIMESTAMP(view_column) incorrectly return NULL
  for a NOT NULL view_column.

Fix:
  Make Item_direct_ref::get_date() calculate null_value
  in the similar way with the other methods 
  (val_real,val_str,val_int,val_decimal):
  copy null_value from the referenced Item.

modified:
  mysql-test/r/func_time.result
  mysql-test/t/func_time.test
  sql/item.cc

                     routines.

mysqldump in xml mode did not dump routines, events or
triggers.

This patch fixes this issue by fixing the if conditions
that disallowed the dump of above mentioned objects in
xml mode, and added the required code to enable dump
in xml format.

Moving query_cache_size_basic_32.test and query_cache_size_basic_64.test from experimental
to disabled as a solution has still not been found.

If we meet DB_TOO_MANY_CONCURRENT_TRXS during the execution tab_create_graph from row_create_table_for_mysql(), .ibd file for the table should be created already but was not deleted for the error handling.

rb:875 approved by Jimmy Yang

If we meet DB_TOO_MANY_CONCURRENT_TRXS during the execution tab_create_graph from row_create_table_for_mysql(), .ibd file for the table should be created already but was not deleted for the error handling.

rb:875 approved by Jimmy Yang

Null merge from  5.1 for Bug 12872803 - 62154: FEDERATED.FEDERATED_SERVER TEST FAILS WITH RUN --REPEAT=2

Fixed it to work with "--repeat" option.

Fixed the testcase using timestamp logic while doing grep from the error file.

Fixed the testcase using timestamp logic while doing grep from the error file.

Use new syntax to mask different error output in affected tests

If init_command was incorrect, we couldn't let users execute
queries, but we couldn't report the issue to the client either
as it does not expect error messages before even sending a
command. Thus, we simply disconnected them without throwing
a clear error.

We now go through the proper sequence once (without executing
any user statements) so we can report back what the problem
is. Only then do we disconnect the user.

As always, root remains unaffected by this as init_command is
(still) not executed for them.

Port vasil.dimov@oracle.com-20111205083046-jtgi1emlvtfnjatt from mysql-trunk

Port vasil.dimov@oracle.com-20111205082900-lx9om1joscejr25e from mysql-trunk

Port vasil.dimov@oracle.com-20111205082831-7v1qu50hvd9hjr3g from mysql-trunk

Port vasil.dimov@oracle.com-20111205082756-wtlg8isyn4yohyny from mysql-trunk

Port vasil.dimov@oracle.com-20111205082626-87j5f48dq1ouk86r from mysql-trunk