into  dl145h.mysql.com:/data0/mkindahl/mysql-5.0-rpl

  
Disable test case for bug 29948, which is causing sporadically
failures in other tests inside mysql_client_test.

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

into  kaamos.(none):/data/src/opt/mysql-4.1-opt

Problem: if the IO slave thread is attempting to connect,
STOP SLAVE waits for the attempt to finish. 
It may take a long time.
Fix: don't wait, stop the slave immediately.

into  mysql.com:/misc/mysql/34749/50-34749

into  mysql.com:/misc/mysql/29645/50-29645

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

Affected tests fixing. After the fix for st_relay_log_info::wait_for_pos() that
handles widely used select('master-bin.xxxx',pos) invoked by mysqltest
there appeared to be four tests that either tried synchronizing when
the slave was stopped or used incorrect synchronization method like
to call `sync_with_master' from the current connection being to the
master itself.

Fixed with correcting the current connection or/and using the correct
synchronization macro when possible.

into  magare.gmz:/home/kgeorge/mysql/autopush/B34909-5.0-opt

  --master-data

No error code was returned by mysqldump if it detects that binary
logging is not enabled on the server.
Fixed by returning error code.

into  mysql.com:/home/psergey/mysql-5.0-bug34945

MASTER_POS_WAIT return values are different than expected when the server is not a slave. 
It returns -1 instead of NULL.

Fixed with correcting  st_relay_log_info::wait_for_pos() to return the proper
value in the case of rli info is not inited.

                    sporadically

Under some circumstances, the mysql_insert_id() value after SELECT ...
INSERT could return a wrong value. This could happen when the last
SELECT ... INSERT did not involve an AUTO_INCREMENT column, but the
value of mysql_insert_id() was changed by some previous statements.

Fixed by checking the value of thd->insert_id_used in
select_insert::send_eof() and returning 0 for mysql_insert_id() if it
is not set.

into  dl145h.mysql.com:/data0/mkindahl/mysql-5.0-rpl

- Apply Eric Bergen's patch: in join_read_always_key(), move ha_index_init() call
  to before the late NULLs filtering code.
- Backport function comments from 6.0.

into  kaamos.(none):/data/src/opt/mysql-5.0-opt

                    with errno 17

my_create() did not perform any checks for the case when a file is
successfully created by a call to open(), but the call to
my_register_filename() later fails because the number of open files
has exceeded the my_open_files limit. This can happen on platforms 
which do not have getrlimit(), and hence we do not know the real limit
for open files. In such a case an error was returned to a caller
although the file has actually been created. Since callers assume
my_create() to return an error only when it failed to create a file,
they did not perform any cleanups, leaving an 'orphaned' file on the
file system.

Fixed by adding a check for the above case to my_create() and ensuring
the newly created file is deleted before returning an error.

Creating a deterministic test case in the test suite is impossible,
because the exact steps required to reproduce the above situation
depend on the platform and/or environment (OS per-user limits, queries
executed by previous tests, startup parameters). The patch was
manually tested on Windows using examples posted in the bug report.

into  host.loc:/home/uchum/work/5.0-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

                  and Item_direct_ref constructor calls.

Order of ref->field_name and ref->table_name arguments
is of Item_ref and Item_direct_ref in the fix_inner_refs
function is inverted.

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

added new function test_if_data_home_dir() which checks that
path does not contain mysql data home directory.
Using of mysql data home directory in
DATA DIRECTORY & INDEX DIRECTORY is disallowed.

must match the order which they were declared in the class definition. 

into  host.loc:/home/uchum/work/5.0-opt

                  Assertion `0' failed

If ROW item is a part of an expression that also has
aggregate function calls (COUNT/SUM/AVG...), a
"splitting" with an Item::split_sum_func2 function
is applied to that ROW item.
Current implementation of Item::split_sum_func2
replaces this Item_row with a newly created
Item_aggregate_ref reference to it.
Then the row cache tries to work with the
Item_aggregate_ref object as with the Item_row object:
row cache calls row-emulation methods such as cols and
element_index. Item_aggregate_ref (like it's parent
Item_ref) inherits dummy implementations of those
methods from the hierarchy root Item, and call to
them leads to failed assertions and wrong data
output.

Row-emulation virtual functions (cols, element_index, addr,
check_cols, null_inside and bring_value) of Item_ref have
been overloaded to forward calls to an underlying item
reference.

The problem is that passing anything other than a integer to a limit
clause in a prepared statement would fail. This limitation was introduced
to avoid replication problems (e.g: replicating the statement with a
string argument would cause a parse failure in the slave).

The solution is to convert arguments to the limit clause to a integer
value and use this converted value when persisting the query to the log.

into  magare.gmz:/home/kgeorge/mysql/autopush/B34747-5.0-opt

NAME_CONST('whatever', -1) * MAX(whatever) bombed since -1 was
not seen as constant, but as FUNCTION_UNARY_MINUS(constant)
while we are at the same time pretending it was a basic const
item. This confused the aggregate handlers in exciting ways.
We now make NAME_CONST() behave more consistently.

Was a double-free of the Unique member of Item_func_group_concat.
This was not causing a crash because the Unique is a descendent of
Sql_alloc.
Fixed to free the Unique only if it was allocated for the instance 
of Item_func_group_concat it was referenced from

Disable the test case.