Visual Studio 2008 Express edition does not include message compiler mc.exe
It is not possible to build MySQL server if only VC2008 Express is installed,
because we use mc.exe to generate event log messages.

This patch removes the mc.exe dependency. Generated files message.h, 
message.rc and MSG00001.bin  are checked into source code repository.
Instructions on how to add or change messages are added to messages.mc

mysql-test/r/xa.result:
  Update test case result.
mysql-test/t/xa.test:
  Drop table used for test.

The problem was that the server did not robustly handle a
unilateral roll back issued by the Resource Manager (RM)
due to a resource deadlock within the transaction branch.
By not acknowledging the roll back, the server (TM) would
eventually corrupt the XA transaction state and crash.

The solution is to mark the transaction as rollback-only
if the RM indicates that it rolled back its branch of the
transaction.

mysql-test/r/xa.result:
  Add test case result for Bug#28323
mysql-test/t/xa.test:
  Add test case for Bug#28323
sql/handler.cc:
  Reset XID only at the end of the global transaction.
sql/share/errmsg.txt:
  Add new error codes.
sql/sql_class.h:
  Remember the error reported by the Resource Manager.
sql/sql_parse.cc:
  Rollback the transaction if the Resource Manager reported
  a error and rolled back its branch of the transaction.

Fixed .test file, re-recorded .result file

Ensured reset of system variables at the end of subtests.

Server crashed during a sort order optimization
of a dependent subquery:

SELECT
    (SELECT t1.a FROM t1, t2
      WHERE t1.a = t2.b AND t2.a = t3.c
      ORDER BY t1.a)
  FROM t3;


Bitmap of tables, that the reference to outer table
column uses, in addition to the regular table bit
has the OUTER_REF_TABLE_BIT bit set.
The only_eq_ref_tables function traverses this map
bit by bit simultaneously with join->map2table list.
Obviously join->map2table never contains an entry
for the OUTER_REF_TABLE_BIT pseudo-table, so the
server crashed there.


The only_eq_ref_tables function has been modified
to traverse regular table bits only like the
update_depend_map function (resetting of the
OUTER_REF_TABLE_BIT there is enough, but
resetting of the whole set of PSEUDO_TABLE_BITS
is used there for sure).


mysql-test/r/order_by.result:
  Added test case for bug #39844.
mysql-test/t/order_by.test:
  Added test case for bug #39844.
sql/sql_select.cc:
  Bug #39844: Query Crash Mysql Server 5.0.67
  
  The only_eq_ref_tables function has been modified
  to traverse regular table bits only like the
  update_depend_map function (resetting of the
  OUTER_REF_TABLE_BIT there is enough, but
  resetting of the whole set of PSEUDO_TABLE_BITS
  is used there for sure).

Added the missing DROP TABLE

mysql-test/r/windows.result:
  Bug #39958: added the missing DROP TABLE
mysql-test/t/windows.test:
  Bug #39958: added the missing DROP TABLE

The problem is that the function used by the server to increase
the thread's priority (pthread_setschedparam) has the unintended
side-effect of changing the calling thread scheduling policy,
possibly overwriting a scheduling policy set by a sysadmin.

The solution is to rely on the pthread_setschedprio function, if
available, as it only changes the scheduling priority and does not
change the scheduling policy. This function is usually available on
Solaris and Linux, but it use won't work by default on Linux as the
the default scheduling policy only accepts a static priority 0 -- this
is acceptable for now as priority changing on Linux is broken anyway.

configure.in:
  Check for the existence of the pthread_setschedprio function.
include/my_pthread.h:
  Use the pthread_setschedprio function to set the thread priority
  if the function is available.

The problem is that MySQL's 'fast' mutex implementation uses the
random() routine to determine the spin delay. Unfortunately, the
routine interface is not thead-safe and some implementations (eg:
glibc) might use a internal lock to protect the RNG state, causing
excessive locking contention if lots of threads are spinning on
a MySQL's 'fast' mutex. The code was also misusing the value
of the RAND_MAX macro, this macro represents the largest value
that can be returned from the rand() function, not random().

The solution is to use the quite simple Park-Miller random number
generator. The initial seed is set to 1 because the previously used
generator wasn't being seeded -- the initial seed is 1 if srandom()
is not called.

Futhermore, the 'fast' mutex implementation has several shortcomings
and provides no measurable performance benefit. Therefore, its use is
not recommended unless it provides directly measurable results.


include/my_pthread.h:
  Add field to keep the RNG state.
mysys/thr_mutex.c:
  Use a palliative per-mutex rng state to determine the spin delay.
  The RNG is not thread-safe but jumping a few sequences in the RNG
  is harmless.

The problem is that the offset argument of the limit clause
might be truncated on a 32-bits server built without big
tables support. The truncation was happening because the
original 64-bits long argument was being cast to a 32-bits
(ha_rows) offset counter.

The solution is to check if the conversing resulted in value
truncation and if so, the offset is set to the maximum possible
value that can fit on the type.

mysql-test/r/limit.result:
  Add test case result for Bug#37075
mysql-test/t/limit.test:
  Add test case for Bug#37075
sql/sql_lex.cc:
  Check for truncation of the offset value. If value was
  truncated, set to the maximum possible value.

If delayed insert fails to upgrade the lock it was not
freeing the temporary memory storage used to keep
newly constructed blob values in memory.
Fixed by iterating over the remaining rows in the delayed
insert rowset and freeing the blob storage for each row.

No test suite because it involves concurrent delayed inserts 
on a table and cannot easily be made deterministic. 

Added a correct valgrind suppression for Fedora 9.

mysql-test/valgrind.supp:
  Added a vagrind suppression for Fedora 9
sql/sql_insert.cc:
  Bug #38693: free the blobs temp storage on error.

The problem is that field names constructed due to wild-card
expansion done inside a stored procedure could point to freed
memory if the expansion was performed after the first call to
the stored procedure.

The problem was solved by patch for Bug#38691. The solution
was to allocate the database, table and field names in the
in the statement memory instead of table memory.

mysql-test/r/sp.result:
  Add test case result for Bug#38823
mysql-test/t/sp.test:
  Add test case for Bug#38823
sql/item.cc:
  Remark that this also impacts wildcard expansion inside SPs.