into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0.46

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

into  bk-internal.mysql.com:/data0/bk/tsmith-tmp/mysql-5.0-maint

  i5 compatibility

  Allow to set mysqld exe suffix

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

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

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

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/41

Fixing bug#25486:  mysqld_multi.server.sh missing from builds

Fixing bug#21023:  "mysql-stress-test.pl" missing in builds

into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

  BUG#29382

into  sin.intern.azundris.com:/home/tnurnberg/27198/50-27198

into  sin.intern.azundris.com:/home/tnurnberg/27198/50-27198

into  sin.intern.azundris.com:/home/tnurnberg/27198/41-27198

into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

selected prior: ensure the fix also works for information_schema
tables.

into  chilla.local:/home/mydev/mysql-5.0-axmrg

into  trift-lap.fambruehe:/MySQL/M50/push-5.0

Linux Debug build (possible deadlock)"

The bug is not repeatable any more.

into  chilla.local:/home/mydev/mysql-5.0-axmrg

into  chilla.local:/home/mydev/mysql-5.0-axmrg

into  chilla.local:/home/mydev/mysql-4.1-axmrg

pseudo_thread_id was reset to zero via mysql_change_user() handling
whereas there is no reason to do that.  Moreover, having two
concurrent threads that change user and create a namesake temp tables
leads to recording the dup pair of queries:

   set @@session.pseudo_thread_id = 0;
   CREATE temporary table `the namesake`;

which will stall the slave as the second instance can not be created.
And that is the bug case.

Fixed by correcting pseudo_thread_id value after mysql_change_user().

gettimeofday() can fail and presumably, so can time().
Keep an eye on it.

Since we have no data on this at all so far, we just
retry on failure (and log the event), assuming that
this is just an intermittant failure. This might of
course hang the threat until we succeed. Once we know
more about these failures, an appropriate more clever
scheme may be picked (only try so many times per thread,
etc., if that fails, return last "good" time() we got or
some such).  Using sql_print_information() to log as this
probably only occurs in high load scenarios where the debug-
trace likely is disabled (or might interfere with testing
the effect).  No test-case as this is a non-deterministic
issue.

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-maint

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb

When opening a new connecgtion, changed mysqltest to prefer a brand new connection slot over an existing, closed slot. Fixes a problem with reused slots that can cause tests to fail. bug#29579

into  damien-katzs-computer.local:/Users/dkatz/50

Added an option to yassl to allow "quiet shutdown" like openssl does. This option causes the SSL libs to NOT perform the close_notify handshake during shutdown. This fixes a hang we experience because we hold a lock during socket shutdown.

into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

incomplete in 5.0 (and review fixes).

When in 5.0.13 I introduced class Prepared_statement and methods
::prepare and ::execute, general logging was left out of this class.
This was good for stored procedures, since in stored procedures
we do not log sub-statements, but introduced a regression in case of SQL
syntax for prepared statements, as previously we would log the actual
statements to the log, and after the change we would log only
COM_QUERY text.

Restore the old behavior, but still suppress logging if inside a stored 
procedure.

Based on a community contributed patch from Vladimir Shebordaev.

No test case since we do not have a mechanism to test output
of the general log.

into  bodhi.(none):/opt/local/work/mysql-5.0-26141-final

causes full table lock on innodb table.
Also fixes Bug#28502 Triggers that update another innodb table 
will block on X lock unnecessarily (duplciate).
Code review fixes.

Both bugs' synopses are misleading: InnoDB table is
not X locked. The statements, however, cannot proceed concurrently, 
but this happens due to lock conflicts for tables used in triggers,
not for the InnoDB table. 

If a user had an InnoDB table, and two triggers, AFTER UPDATE and 
AFTER INSERT, competing for different resources (e.g. two distinct
MyISAM tables), then these two triggers would not be able to execute
concurrently. Moreover, INSERTS/UPDATES of the InnoDB table would
not be able to run concurrently. 
The problem had other side-effects (see respective bug reports).

This behavior was a consequence of a shortcoming of the pre-locking
algorithm, which would not distinguish between different DML operations
(e.g. INSERT and DELETE) and pre-lock all the tables
that are used by any trigger defined on the subject table.

The idea of the fix is to extend the pre-locking algorithm to keep track,
for each table, what DML operation it is used for and not
load triggers that are known to never be fired.

into  adventure.(none):/home/thek/Development/cpp/mysql-5.0-runtime