into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0-rt-merged

            localhost/default port

When creating federated table that points to unspecified host or
localhost on unspecified port or port is 0, small memory leak occurs.

This happens because we make a copy of unix socket path, which is
never freed.

With this fix we do not make a copy of unix socket path, instead
share->socket points to MYSQL_UNIX_ADDR constant directly.

This fix is covered by a test case for BUG34788.

Affects 5.0 only.

            correctly - crashes server !

Creating federated table with connect string containing empty
(zero-length) host name and port is evaluated as 0 (port is
incorrect, omitted or 0) crashes server.

This happens because federated calls strcmp() with NULL pointer.

Fixed by avoiding strcmp() call if hostname is set to NULL.

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

The problem is that unimplemented WIN32 version of pthread_kill
is returning ESRCH no matter the arguments, causing calls to
mysqld_list_processes to set the procinfo to dead because
pthread_kill returns non zero. The dead procinfo would show
up on a second invocation of show processlist.

into  quad.opbmk:/mnt/raid/alik/MySQL/devel/5.0-rt-merged

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0

The problem was that the COM_STMT_SEND_LONG_DATA was sending a response
packet if the prepared statement wasn't found in the server (due to
reconnection). The commands COM_STMT_SEND_LONG_DATA and COM_STMT_CLOSE
should not send any packets, even error packets should not be sent since
they are not expected by the client API.

The solution is to clear generated during the execution of the aforementioned
commands and to skip resend of prepared statement commands. Another fix is
that if the connection breaks during the send of prepared statement command,
the command is not sent again since the prepared statement is no longer in the
server.

into  pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0

into  pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0

into  stella.local:/home2/mydev/mysql-5.0-axmrg

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

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  mysql.com:/home/svoj/devel/mysql/BUG28248/mysql-5.0-engines

When there are no underlying tables specified for a merge table,
SHOW CREATE TABLE outputs a statement that cannot be executed. The
same is true for mysqldump (it generates dumps that cannot be
executed).

This happens because SQL parser does not accept empty UNION() clause.

This patch changes the following:
- it is now possible to execute CREATE/ALTER statement with
  empty UNION() clause.
- the same as above, but still worth noting: it is now possible to
  remove underlying tables mapping using ALTER TABLE ... UNION=().
- SHOW CREATE TABLE does not output UNION() clause if there are
  no underlying tables specified for a merge table. This makes
  mysqldump slightly smaller.

            log-slave-updates and circul repl

This is a test case fix for BUG#13861.

into  stella.local:/home2/mydev/mysql-5.0-axmrg

When concurrent inserts were disabled, statements after an INSERT
were not put into the query cache. This happened because we do not
save the current data file length at statement start when
concurrent inserts are disabled. But we checked the always zero
local length against the real file length anyway.
  
Fixed by doing the check only if concurrent inserts are not diabled.

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

The test file tried to use a mysqltest command '--warning'
but there is no such command.

Changed '--warning' to '#--warning'.

  
In cases when TRUNCATE was executed by invoking mysql_delete() rather
than by table recreation (for example, when TRUNCATE was issued on
InnoDB table with is referenced by foreign key) triggers were invoked.
In debug builds this also led to crash because of an assertion, which
assumes that some preliminary actions take place before trigger 
invocation, which doesn't happen in case of TRUNCATE.

The fix is not to execute triggers in mysql_delete() when this
function is used by TRUNCATE.

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

into  pcg5ppc.xiphis.org:/Network/Servers/anubis.xiphis.org/home/antony/work/merge.20080307/mysql-5.0

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.