read buffer
Setting read buffer to values greater than SSIZE_MAX results in
unexpected behavior.

According to read(2) manual:
If count is greater than SSIZE_MAX, the result is unspecified.

Set upper limit for read_buffer_size and read_rnd_buffer_size to
SSIZE_MAX.

into  mysql.com:/home/mydev/mysql-5.0-bug19604

CHECK TABLE did temporarily clear the auto_increment value.
It runs with a read lock, allowing other readers and
conurrent INSERTs. The latter could grab the wrong value
in this moment.

CHECK TABLE does no longer modify the auto_increment value.
Not even for a short moment.

  "Merge table does not work with bit types"
   MERGE should have HA_CAN_BIT_FIELD feature bit set or else table row is
   formatted incorrectly.

The order of acquiring LOCK_mysql_create_db
and wait_if_global_read_lock() was wrong. It could happen
that a thread held LOCK_mysql_create_db while waiting for
the global read lock to be released. The thread with the
global read lock could try to administrate a database too.
It would first try to lock LOCK_mysql_create_db and hang...

The check if the current thread has the global read lock
is done in wait_if_global_read_lock(), which could not be
reached because of the hang in LOCK_mysql_create_db.

Now I exchanged the order of acquiring LOCK_mysql_create_db
and wait_if_global_read_lock(). This makes 
wait_if_global_read_lock() fail with an error message for
the thread with the global read lock. No deadlock happens.

into  april.(none):/home/svoj/devel/mysql/BUG18233/mysql-5.0

            SELECT WHERE a= AND b=

Selecting data from memory table with varchar column and hash index over it
returns only first row matched.

Problem was that key length calculation for varchar columns didn't include
number of bytes to store length.

Fixed key length for varchar fields to include number of bytes to store length.

into  xiphis.org:/home/antony/work2/mysql-5.0-engines-merge

into  xiphis.org:/home/antony/work2/p1-bug10952.1

  "alter table from MyISAM to MERGE lost data without errors and warnings"
  Add new handlerton flag which prevent user from altering table storage
  engine to storage engines which would lose data. Both 'blackhole' and 
  'merge' are marked with the new flag.
  Tests included.

into  mysql.com:/home/marty/MySQL/mysql-5.0

into  mysql.com:/home/marty/MySQL/mysql-5.0

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

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

No commit message

into mysql.com:/Users/kent/mysql/bk/mysql-5.0-new

Add function 'vio_end' that will cleanup resources allocated by vio and the components it uses.

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

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

into  rurik.mysql.com:/home/igor/mysql-5.0

into  rurik.mysql.com:/home/igor/dev/mysql-5.0-0

into  rurik.mysql.com:/home/igor/mysql-4.1

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136

recalculating results

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/Merge/5.0-bug19136

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/4.1-bug19136_unass_user_var

A query with a group by and having clauses could return a wrong
result set if the having condition contained a constant conjunct 
evaluated to FALSE.
It happened because the pushdown condition for table with
grouping columns lost its constant conjuncts.
Pushdown conditions are always built by the function make_cond_for_table
that ignores constant conjuncts. This is apparently not correct when
constant false conjuncts are present.

into mysql.com:/home/psergey/mysql-5.0-bug16798-merge

into mysql.com:/home/psergey/mysql-4.1-bug16798

into  mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-merge

into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501

into  mysql.com:/home/tomash/src/mysql_ab/mysql-4.1-bug16501

into  mysql.com:/home/mydev/mysql-4.1-bug10405

into  mysql.com:/home/mydev/mysql-5.0-bug10405

into mysql.com:/home/psergey/mysql-4.1-bug16798

into mysql.com:/home/psergey/mysql-5.0-bug16798-merge