into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21414

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-runtime

Remove race situations that occur when removing pidfiles. Primarily each process should remove its own
pidfile, secondly it should be removed by the process that created it and _only_ if it's
certain the process is dead. Third, mysql-test-run.pl will remove the pidfile when process has been killed.
- Set state of an instance to STARTING _before_ calling instance->start()
- Check that pidfile of instance has been created before changing STARTING => STARTED
- Only remove the pidfile if IM kills an instance with SIGKILL, otherwise the instance will remove it itself

The problem was that if after FLUSH TABLES WITH READ LOCK the user
issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as
expected), but after UNLOCK TABLE any attempt to execute the same
operation would lead to the error 1305 "PROCEDURE/FUNCTION does not
exist", and an attempt to execute any stored function will also fail.

This happened because under FLUSH TABLES WITH READ LOCK we couldn't open
and lock mysql.proc table for update, and this fact was erroneously
remembered by setting mysql_proc_table_exists to false, so subsequent
statements believed that mysql.proc doesn't exist, and thus that there
are no functions and procedures in the database.

As a solution, we remove mysql_proc_table_exists flag completely.  The
reason is that this optimization didn't work most of the time anyway.
Even if open of mysql.proc failed for some reason when we were trying to
call a function or a procedure, we were setting mysql_proc_table_exists
back to true to force table reopen for the sake of producing the same
error message (the open can fail for number of reasons).  The solution
could have been to remember the reason why open failed, but that's a lot
of code for optimization of a rare case.  Hence we simply remove this
optimization.

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

to start instance manager.

The problem was that if IM failed to start, test suite aborts.

The fix is to mark current test as failed, and continue running
test suite.

The fix affects only test suite.

The patch affects only test suite and has the following changes:

1. On starting Instance Manager -- added code for waiting for guarded
mysqld instances to create PID files;
2. Polishing;
3. Move IM-related operations out of mtr_process.pl into new dedicated
for IM file -- mtr_im.pl

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

into  trift2.:/M50/push-5.0

To be pushed to both the cloned 5.0.25 and the general 5.0 tree.

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

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

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

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

In 5.0 we made LOAD DATA INFILE autocommit in all engines, while
only NDB wanted that. Users and trainers complained that it affected
InnoDB and was a change compared to 4.1 where only NDB autocommitted.
To revert to the behaviour of 4.1, we move the autocommit logic out of mysql_load() into
ha_ndbcluster::external_lock().
The result is that LOAD DATA INFILE commits all uncommitted changes
of NDB if this is an NDB table, its own changes if this is an NDB
table, but does not affect other engines.
Note: even though there is no "commit the full transaction at end"
anymore, LOAD DATA INFILE stays disabled in routines (re-entrency
problems per a comment of Pem).
Note: ha_ndbcluster::has_transactions() does not give reliable results
because it says "yes" even if transactions are disabled in this engine...

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

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb

into  perch.ndb.mysql.com:/home/jonas/src/50-work

  fix deadlock if master switches log file in parallell with "show master logs"
  

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

Fix problem where mysql-test-run.pl fails to start up the mysqld after a failed test. Shows up on win hosts where one failed test case make subsequent ones fails with error "Could not open connection 'default': 2003 Can't connect to MySQL server on 'localhost'" 

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  maint1.mysql.com:/data/localhome/tnurnberg/my50-21913

into  salvation.intern.azundris.com:/home/tnurnberg/21913/my50-21913

21913: DATE_FORMAT() Crashes mysql server if I use it through mysql-connector-j driver.

Variable character_set_results can legally be NULL (for "no conversion.")
This could result in a NULL deref that crashed the server.  Fixed.

(Although ran some additional precursory tests to see whether I could break
anything else, but no breakage so far.)

Variable character_set_results can legally be NULL (for "no conversion.")
This could result in a NULL deref that crashed the server.  Fixed.

(Although ran some additional precursory tests to see whether I could break
anything else, but no breakage so far.)

into  maint1.mysql.com:/data/localhome/tsmith/bk/mysql-5.0-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0

into  bk-internal.mysql.com:/data0/bk/mysql-5.0-cmake

into  maint2.mysql.com:/data/localhome/tsmith/bk/50

into  bk-internal.mysql.com:/data0/bk/mysql-5.0-cmake

into  maint1.mysql.com:/data/localhome/cmiller/mysql-5.0-maint

  Provide a more extensible, easier-to-change way of reordering
  test cases.