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


heap/hp_write.c:
  Auto merged
mysql-test/r/heap_btree.result:
  Auto merged
mysql-test/t/heap_btree.test:
  Bug#26996 - Update of a Field in a Memory Table ends with wrong result
  Manual merge from 4.1

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.


heap/hp_write.c:
  Bug#26996 - Update of a Field in a Memory Table ends with wrong result
  Removed the index-scan-breaking nulling of last_pos.
  The comment behind this line ("For heap_rnext/heap_rprev")
  was misleading. It should have been "Breaks heap_rnext/heap_rprev".
mysql-test/r/heap_btree.result:
  Bug#26996 - Update of a Field in a Memory Table ends with wrong result
  Added test result.
mysql-test/t/heap_btree.test:
  Bug#26996 - Update of a Field in a Memory Table ends with wrong result
  Added test.

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


sql/ha_myisam.cc:
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  Manual merge from 4.1

            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.


sql/ha_myisam.cc:
  Bug#25289 - repair table causes "my_seek.c:56:
              my_seek: Assertion `fd != -1' failed"
  Added code to detect a closed data file. It could be closed
  by a preceeding repair attempt. We must not try another
  repair then.

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


mysql-test/t/merge.test:
  Auto merged
mysql-test/r/merge.result:
  Bug#26464 - insert delayed + update + merge = corruption
  Manual merge from 4.1
sql/ha_myisammrg.h:
  Bug#26464 - insert delayed + update + merge = corruption
  Manual merge from 4.1

Using INSERT DELAYED on MERGE tables could lead to table
corruptions.

The manual lists a couple of storage engines, which can be
used with INSERT DELAYED. MERGE is not in this list.

The attempt to try it anyway has not been rejected yet.
This bug was not detected earlier as it can work under
special circumstances. Most notable is low concurrency.

To be safe, this patch rejects any attempt to use INSERT
DELAYED on MERGE tables.


mysql-test/r/merge.result:
  Bug#26464 - insert delayed + update + merge = corruption
  Added test result.
mysql-test/t/merge.test:
  Bug#26464 - insert delayed + update + merge = corruption
  Added test.
sql/ha_myisammrg.h:
  Bug#26464 - insert delayed + update + merge = corruption
  Removed HA_CAN_INSERT_DELAYED flag from table_flags().
  The insert delayed thread upgrades the lock from the first
  entry in MYSQL_LOCK::locks only. Hence it is incapable to
  handle MERGE tables, which have as many entries in this
  array as they have MyISAM sub-tables.

INSERT DELAYED inserts garbage for BIT columns.

When delayed thread clones TABLE object, it didn't adjusted bit_ptr
to newly created record (though it correctly adjusts ptr and null_ptr).

This is fixed by correctly adjusting bit_ptr when performing a clone.
With this fix BIT values are stored correctly by INSERT DELAYED.


mysql-test/r/delayed.result:
  A test case for BUG#26238.
mysql-test/t/delayed.test:
  A test case for BUG#26238.
sql/field.h:
  Added move_field() to Field_bit class. When moving a field, adjust
  bit_ptr also, which is specific to Field_bit class.

into  bk-internal.mysql.com:/data0/bk/mysql-5.0-engines

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

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint


sql/mysql_priv.h:
  Auto merged

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


sql/item.cc:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/item_cmpfunc.h:
  Auto merged
sql/sql_select.cc:
  Auto merged

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


mysys/my_pthread.c:
  SCCS merged

into  bk-internal.mysql.com:/data0/bk/mysql-5.0-opt


BitKeeper/etc/gone:
  auto-union
mysys/my_getopt.c:
  Auto merged
sql/field.h:
  Auto merged
sql/item.cc:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/item_cmpfunc.h:
  Auto merged
sql/mysql_priv.h:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
sql/sql_select.cc:
  Auto merged
sql/table.cc:
  Auto merged
mysql-test/r/select.result:
  Manual merge
mysql-test/t/select.test:
  Manual merge

Showstopper and regression against 5.0.24.

Previously, we ignored seek() errors (see Bug#22828) and let seek()s
against pipes fail.  Now, since we check that a seek didn't fail,
and return without reading, this bug popped up.

This restores the behavior for file-ish objects that could never be 
seek()ed.


mysys/mf_iocache.c:
  If we detect early that the file is not tell()able, then we should
  assume that it's also not seek()able and therefore we should never
  set the (poorly named) "seek_not_done" flag so that we don't immedi-
  ately try to seek() when reading later.
  
  The problem was that tell() was returning -1, so when we read later, 
  we needlessly tried to seek to position  (unsigned long) -1 . 
  
  Also, if we think we're supposed to seek to a position in a file and 
  the file is un-tell()able, then abort.

into  bk-internal.mysql.com:/data0/bk/mysql-4.1-opt

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint


sql/item.cc:
  Auto merged
sql/item_cmpfunc.cc:
  Auto merged
sql/item_cmpfunc.h:
  Auto merged
sql/sql_select.cc:
  Auto merged

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint


sql/mysql_priv.h:
  Auto merged

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint


BitKeeper/etc/ignore:
  auto-union

into  pilot.mysql.com:/home/msvensson/mysql/mysql-5.0-maint


BitKeeper/etc/gone:
  auto-union
mysys/my_getopt.c:
  Auto merged
sql/sql_prepare.cc:
  Auto merged
sql/table.cc:
  Auto merged

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26209


sql/sql_select.cc:
  Auto merged

into  mysql.com:/home/hf/work/25492/my50-25492


sql/item.cc:
  Auto merged

into  mysql.com:/home/hf/work/25492/my50-25492

into  mysql.com:/home/hf/work/25492/my41-25492

into  mysql.com:/home/hf/work/25492/my50-25492


libmysqld/lib_sql.cc:
  merging

libmysqld/lib_sql.cc:
  code modified to prevent freeing of memory that wasn't malloc-ed.
  Now we check if MYSQL_STMT::result was used.

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

into  mysql.com:/home/gluh/MySQL/Merge/5.0-opt

 Common symbols with and without initialization
 cause the apple linker to exclude then from the
 list of global symbols.

into  mysql.com:/home/tnurnberg/24660/50-24660


sql/table.cc:
  Auto merged
sql/unireg.cc:
  Auto merged

into  mysql.com:/home/tnurnberg/24660/41-24660


sql/table.cc:
  Auto merged

into  mysql.com:/home/tnurnberg/24660/50-24660


mysql-test/r/type_enum.result:
  Auto merged
sql/table.cc:
  Auto merged
sql/unireg.cc:
  Auto merged

ENUMs weren't allowed to have character 0xff, a perfectly good character in some locales.
This was circumvented by mapping 0xff in ENUMs to ',', thereby prevent actual commas from
being used. Now if 0xff makes an appearance, we find a character not used in the enum and
use that as a separator. If no such character exists, we throw an error.

Any solution would have broken some sort of existing behaviour. This solution should
serve both fractions (those with 0xff and those with ',' in their enums), but
WILL REQUIRE A DUMP/RESTORE CYCLE FROM THOSE WITH 0xff IN THEIR ENUMS. :-/
That is, mysqldump with their current server, and restore when upgrading to one with
this patch.


mysql-test/r/type_enum.result:
  Bug#24660: "enum" field type definition problem
  
  Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
  char in some locales), or ',', or both.
mysql-test/t/type_enum.test:
  Bug#24660: "enum" field type definition problem
  
  Show that enums can now contain NAMES_SEP_CHAR (0xff, which is a perfectly respectable
  char in some locales), or ',', or both.
sql/table.cc:
  Bug#24660: "enum" field type definition problem
  
  Revert fix for Bug#20922.
sql/unireg.cc:
  Bug#24660: "enum" field type definition problem
  
  Use a field-separator for ENUM-values that is not part of those values. If impossible,
  throw error.

The crash happens because second filling of the same I_S table happens in
case of subselect with order by. table->sort.io_cache previously allocated
in create_sort_index() is deleted during second filling
(function get_schema_tables_result). There are two places where
I_S table can be filled: JOIN::exec and create_sort_index().
To fix the bug we should check if the table was already filled
in one of these places and skip processing of the table in second.


mysql-test/r/information_schema.result:
  test case
mysql-test/t/information_schema.test:
  test case
sql/mysql_priv.h:
  added new parameter 'executed_place' to function get_schema_tables_result()
sql/sql_select.cc:
  added new parameter 'executed_place' to function get_schema_tables_result()
sql/sql_show.cc:
  added more accurate check for cases when we need to refresh I_S table
sql/table.cc:
  added more accurate check for cases when we need to refresh I_S table
sql/table.h:
  added more accurate check for cases when we need to refresh I_S table

Some fields (GEOMETRY first of all) can't be handled properly in this
case at all. So we return an error in this case


mysql-test/r/default.result:
  result fixed
mysql-test/r/gis.result:
  result fixed
mysql-test/t/default.test:
  VIEW test added
mysql-test/t/gis.test:
  testcase added
sql/item.cc:
  set_defaults() changed with the 'reset()'

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug26159

The function make_unireg_sortorder ignored the fact that any
view field is represented by a 'ref' object.
This could lead to wrong results for the queries containing
both GROUP BY and ORDER BY clauses.


mysql-test/r/view.result:
  Added a test case for bug #26209.
mysql-test/t/view.test:
  Added a test case for bug #26209.