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

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

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

  "CREATE/DROP/ALTER SERVER should require privileges"
  Add check for SUPER privilege when executing CREATE/DROP/ALTER SERVER.
  Previously, any user even with only USAGE priv can execute those commands.

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

The previous two patches for this bug worked together so that
no permanent table was memory mapped. The first patch tried to
avoid mapping while a table is in use. It allowed mapping only
if there was exactly one lock on the table, assuming that the
calling thread owned it. During mi_open(), a different call to
memory mapping was coded, which did not have this limitation.

The second patch tried to remove the code duplication and just
called mi_extra() from mi_open() an thus inherited the limitation.
But on open, a thread does not have a lock on the table...

A possible solution would be to check for zero or one lock.
But since I learned that it is safe to memory map a file while
normal file I/O is done on it, I removed the restriction altogether
and allow to memory map while a table is in use.

No test case. I do not see a chance to verify with the test suite
which kind of I/O is used on a table.