into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/push-5.0

into  rhel5-ia64-a.mysql.com:/data0/tsmith/build/50

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-build

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  trift2.:/MySQL/M50/push-5.0

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.

into  mysql.com:/home/kent/bk/build/mysql-5.0-build

into  mysql.com:/home/kent/bk/build/mysql-4.1-build

            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

	isn't running

Pass the process id of the manager as a parameter to "wait_for_pid"
and if the manager isn't running, then do not continue to wait.

Also, capture the error message of our process-existence test, 
"kill -0", as we expect errors and shouldn't pass them to the user.  
Additionally, be a bit more descriptive of what the problem is.

into  ramayana.hindu.god:/home/tsmith/m/bk/build/50

into  ramayana.hindu.god:/home/tsmith/m/bk/build/50

into  trift2.:/MySQL/M50/push-5.0

into  trift2.:/MySQL/M50/man8-5.0

into  trift2.:/MySQL/M41/push-4.1

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  trift2.:/MySQL/M41/push-4.1

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

into  mysql.com:/data0/mysqldev/my/build-200802282059-4.1.24/mysql-4.1-release

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