Item_func_div didn't calculate the precision of the result properly.
  The result of 5/0.0001 is 5000 so we have to add decimals of the divisor
  to the planned precision.

per-file comments:
  mysql-test/r/type_newdecimal.result
Bug#31616 div_precision_increment description looks wrong
    test result fixed

  mysql-test/t/type_newdecimal.test
Bug#31616 div_precision_increment description looks wrong
    test case

  sql/item_func.cc
Bug#31616 div_precision_increment description looks wrong
    precision must be increased with args[1]->decimals parameter

            missing after downgrade

Obsolete arc/ directory and view .frm file backup support
has been removed by the patch for bug 17823. However, that
bugfix caused a problem with "live downgrades" of the
server: if we rename some view 4 times under 5.1.29/5.0.72
and then try to rename it under 5.1.28/5.0.70 on the same
database, the server fails with a error:

  query 'RENAME TABLE ... TO ...' failed: 6: Error on
  delete of '....frm-0001' (Errcode: 2)

Also .frm file of that view may be lost (renamed to .frm~).

The server failed because it tried to rename latest 3
backup .frm files renaming the view: the server used an
integer value of the "revision" field of .frm file to
extract those file names. After the fix for bug 17823 those
files were not created/maintained any more, however the
"revision" field was incremented as usual. So, the server
failed renaming non existent files.

This fix solves the problem by removing the support for
"revision" .frm file field:
1. New server silently ignores existent "revision" fields
   in old .frm files and never write it down;
2. Old server assumes, that missing "revision" field in new
   .frm files means default value of 0.
3. Accordingly to the fix for bug 17823 the new server
   drops arc/ directory on alter/rename view, so after
   "live downgrade" old server begins maintenance of the
   arc/ directory from scratch without conflicts with .frm
   files.

tables can cause server to crash!

The bug will be fixed by patch for #34779: "crash in checksum table
on federated tables with blobs containing nulls"

Only a test case commited.

when InnoDB frm file corruption

Problem: mysqlcheck runs 'SHOW FULL TABLE' queries to get table lists.
The query may fail for some reasons (e.g. null .frm file) then
mysqlcheck doesn't process the database tables.

Fix: try to run 'SHOW TABLES' if 'SHOW FULL TABLES' failed.

Reordered include files so that no mess will be left if this test is run without InnoDB
Previously, this test would leave a database named 'federated' in such a case and would
cause tests that examined existing databases to fail.

issue 'The storage engine for the table doesn't support check' note for I_S tables

japanese characters.

Fix - removed obsolvete setlocale from my_init.c . In MBCS 
environments it caused unwanted character-to-byte translations
in fputc()  in client code and wrong output as result.

Prevent this by modifying CFLAGS and CXXFLAGS.

implicit command which isn't completed immediately.

A string buffers which were included in the 'view' data structure
were allocated on the stack, causing an invalid pointer when used
after the function returned.
The fix: use copy of values for view->md5 & view->queries

1. Replace --sleep by wait_* primitive
2. Vertical output for SHOW SLAVE STATUS
3. Updated result file

- Make send_row_on_empty_set() return FALSE when simplify_cond() has found out
  that HAVING is always FALSE
re-committing to put the fix into 5.0 and 5.1

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

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.

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.

fails after the first time
  
Two separate problems : 
  1. When flattening joins the linked list used for name resolution 
  (next_name_resolution_table) was not updated.
  Fixed by updating the pointers when extending the table list
  
  2. The items created by expanding a * (star) as a column reference
  were marked as fixed, but no cached table was assigned to them 
  (unlike what Item_field::fix_fields does).
  Fixed by assigning a cached table (so the re-preparation is done
  faster).
  
Note that the fix for #2 hides the fix for #1 in most cases
(except when a table reference cannot be cached).

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).

Added the missing DROP TABLE

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.

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.

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.

This time the inclusion of <stdio.h> before "config.h" enabled legacy large
file support, seek64() and similar, on AIX breaking the compile of "gzio.c"

Merge conflicts in test "create:
- for "create.result", handled correctly by "bzr extmerge" (using "kdiff3"),
- for "create.test", not reported as a conflict, but merged wrong
  (new block at the test end got duplicated), fixed manually.

Test on Linux (Debian, PowerPC) was ok.