into  chilla.local:/home/mydev/mysql-5.1-bug24985

into  chilla.local:/home/mydev/mysql-5.1-bug24985

            causes incorrect duplicate entries
After merge fix

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

            causes incorrect duplicate entries

Keys for BTREE indexes on ENUM and SET columns of MEMORY tables
with character set UTF8 were computed incorrectly. Many
different column values got the same key value.

Apart of possible performance problems, it made unique indexes
of this type unusable because it rejected many different
values as duplicates.

The problem was that multibyte character detection was tried
on the internal numeric column value. Many values were not
identified as characters. Their key value became blank filled.

Thanks to Alexander Barkov and Ramil Kalimullin for the patch,
which sets the character set of ENUM and SET key segments to
the pseudo binary character set.

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

Accessing a file that is bigger than 2G may report that read/write operation
failed. This may affect anything that uses my_pread/my_pwrite functions, e.g.
MyISAM, ARCHIVE, binary log.

For MyISAM INSERT may report that table is crashed when writing to a table
that is bigger than 2G.

This is fixed by using proper offset type in my_pread/my_pwrite functions on
systems that do not have native pread/pwrite calls.

Affects systems that do not have native pread/pwrite calls, e.g. Windows.

No test case for this fix, since it requires huge table.

* Modified Federated memory allocation to use MEM_ROOT
* Modified sql_servers and federated to allocate share connection
  parameters to use MEM_ROOT
* Modified Federated to allow tablename in addition to server name
* Implicit flushing of tables using altered/dropped server name
* Added tests to prove new functionality works

Contributors to this patch: Patrick Galbraith, Antony Curtis

  "Concurrent ALTER/CREATE SERVER can lead to deadlock"
  Deadlock caused by inconsistant use of mutexes in sql_server.cc
  One mutex has been removed to resolve deadlock.
  Many functions were made private which should not be exported.
  Unused variables and function removed.

into  chilla.local:/home/mydev/mysql-5.1-bug26782

After merge fix
In conjunction with the newest 5.1 we always need to
create a real path name to be able to detect already
open tables.

into  chilla.local:/home/mydev/mysql-5.1-bug26996

into  chilla.local:/home/mydev/mysql-5.1-bug26996

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

into  mysql.com:/home/svoj/devel/mysql/BUG25908/mysql-5.1-engines

Opening certain tables that have different definitions in .MYI and
.frm may result in a server crash.

Compare .MYI and .frm definition when myisam table is opened. In case
definitions are diffirent refuse to open such table.

No test case, since it requires broken table.

Using a MEMORY table BTREE index for scanning for updatable rows
could lead to an infinite loop.

Everytime a key was inserted into a btree index, the position
in the index scan was cleared. The search started from the
beginning and found the same key again.

Now we do not clear the position on key insert an more.

into  chilla.local:/home/mydev/mysql-5.1-bug26782

into  blade08.mysql.com:/data0/istruewing/autopush/mysql-5.1-bug25289

into  xiphis.org:/home/antony/work2/p1-bug25671.4

into  chilla.local:/home/mydev/mysql-5.1-bug25289

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

into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg25966

into  mockturtle.local:/home/dlenev/src/mysql-5.0-bg25966-2

TABLE ... WRITE".

Memory and CPU hogging occured when connection which had to wait for table
lock was serviced by thread which previously serviced connection that was
killed (note that connections can reuse threads if thread cache is enabled).
One possible scenario which exposed this problem was when thread which
provided binlog dump to replication slave was implicitly/automatically
killed when the same slave reconnected and started pulling data through
different thread/connection.
The problem also occured when one killed particular query in connection
(using KILL QUERY) and later this connection had to wait for some table
lock.

This problem was caused by the fact that thread-specific mysys_var::abort
variable, which indicates that waiting operations on mysys layer should
be aborted (this includes waiting for table locks), was set by kill
operation but was never reset back. So this value was "inherited" by the
following statements or even other connections (which reused the same
physical thread). Such discrepancy between this variable and THD::killed
flag broke logic on SQL-layer and caused CPU and memory hogging.

This patch tries to fix this problem by properly resetting this member.

There is no test-case associated with this patch since it is hard to test
for memory/CPU hogging conditions in our test-suite.

TABLE ... WRITE".

CPU hogging occured when connection which had to wait for table lock was
serviced by thread which previously serviced connection that was killed
(note that connections can reuse threads if thread cache is enabled).
One possible scenario which exposed this problem was when thread which
provided binlog dump to replication slave was implicitly/automatically
killed when the same slave reconnected and started pulling data through
different thread/connection.
In 5.* versions memory hogging was added to CPU hogging. Moreover in
those versions the problem also occured when one killed particular query
in connection (using KILL QUERY) and later this connection had to wait for
some table lock.

This problem was caused by the fact that thread-specific mysys_var::abort
variable, which indicates that waiting operations on mysys layer should
be aborted (this includes waiting for table locks), was set by kill
operation but was never reset back. So this value was "inherited" by the
following statements or even other connections (which reused the same
physical thread). Such discrepancy between this variable and THD::killed
flag broke logic on SQL-layer and caused CPU and memory hogging.

This patch tries to fix this problem by properly resetting this member.

There is no test-case associated with this patch since it is hard to test
for memory/CPU hogging conditions in our test-suite.

into  mockturtle.local:/home/dlenev/src/mysql-5.1-bg25966

into  mysql.com:/home/kent/bk/tmp/mysql-5.1-build

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

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

  Updated to version 0.6 of the text

            my_seek: Assertion `fd != -1' failed"

In difficult optimize/repair situations the server could crash.
Under some circumstances the server retries an optimize/repair
with more elaborate options. But it did not check if the first
attempt failed so badly that a second one must not be tried.

This could happen when a new data file has been created
but it was not possible to open it. In this case the
repair leaves behind a table with closed data file.
This must not be used for another repair attempt.

We do now detect the closed data file and do not try
another repair attempt in this situation.

No test case. The required table corruption can not be
repeated easily. There is a test program attached to
bug 25433.

into  mysql.com:/home/kent/bk/tmp/mysql-5.1-build

into  mysql.com:/home/kent/bk/tmp/mysql-5.1-build

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

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

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

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

  Added test for sched_yield() possibly in -lposix4 on Solaris