Multiple-result processing is required during the execution
of CALL statements for stored procedures, however the mysqlslap
client lacked that processing.

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  trift2.:/MySQL/M51/tmp-5.1

into  trift2.:/MySQL/M51/tmp-5.1

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

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

  Post-merge fix.

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  bk-internal.mysql.com:/data0/bk/mysql-5.1-opt

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

in get_index_for_order(), don't walk over the end of the index key parts
when matching index description and needed ordering.

into  mysql.com:/home/hf/work/28430/my51-28430

In the ha_partition::position() we don't calculate the number
of the partition of the record, but use m_last_part value instead,
relying on that it's previously set by some other call like ::write_row().
Delete_rows_log_event::do_exec_row() calls find_and_fetch_row(),
where we used position() + rnd_pos() call for the InnoDB-based PARTITION-ed
table as there HA_PRIMARY_KEY_REQUIRED_FOR_POSITION enabled.

fixed by introducing new handler::rnd_pos_by_record() method to be
used for random record-based positioning

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

  Post-merge fix.

into  moksha.local:/Users/davi/mysql/push/mysql-5.1-runtime

the first query is not running while we are doing wait queries on
a second connection.

  Post-merge fix.

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  omega.weblab:/home/malff/TREE/mysql-5.1-rt-merge

into  omega.weblab:/home/malff/TREE/mysql-5.1-cleanup

Fixed test failure under heavy load, in case truncate table is slow.

the first query is not running while we are doing wait queries on
a second connection.

into  gleb.loc:/home/uchum/work/bk/5.1-opt

mysqldump --skip-events --all-databases dumped data of the mysqld.event table,
and during the restoration from this dump events were created in spite
of the --skip-events option.

The mysqldump client has been modified to ignore mysql.event table data
in case of --skip-events options.

Discovered a bug while working with backup. Since it is possible to execute a statement in a pre/post statment clause that can return a result, we need to test for that and free it. 

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt50-merge