When using concurrent insert with parallel index reads, it could
happen that reading sessions found keys that pointed to records
yet to be written to the data file. The result was a report of
a corrupted table. But it was false alert.

When inserting a record in a table with indexes, the keys are
inserted into the indexes before the record is written to the data
file. When the insert happens concurrently to selects, an
index read can find a key that references the record that is not
yet written to the data file. To avoid any access to such record,
the select saves the current end of file position when it starts.
Since concurrent inserts are always appended at end of the data
file, the select can easily ignore any concurrently inserted record.

The problem was that the ignore was only done for non-exact key
searches (partial key or using >, >=, < or <=).

The fix is to ignore concurrently inserted records also for
exact key searches.

No test case. Concurrent inserts cannot be tested with the test
suite. Test cases are attached to the bug report.


myisam/mi_rkey.c:
  Bug#29838 - myisam corruption using concurrent select ... and update
  Fixed mi_rkey() to always ignore records beyond saved eof.

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

This bug manifested itself for join queries with GROUP BY and HAVING clauses
whose SELECT lists contained DISTINCT. It occurred when the optimizer could
deduce that the result set would have not more than one row.
The bug could lead to wrong result sets for queries of this type because
HAVING conditions were erroneously ignored in some cases in the function
remove_duplicates.   


mysql-test/r/having.result:
  Added a test case for bug #29911.
mysql-test/t/having.test:
  Added a test case for bug #29911.

unpack_fields() didn't expect NULL_LENGHT in the field's descriptions.
In this case we get NULL in the resulting string so cannot use
strdup_root to make a copy of it.
strdup_root changed with strmake_root as it's NULL-safe


sql-common/client.c:
  Bug #29494 Field packet with NULL fields crashes libmysqlclient
  
  strdup_root changed with strmake_root in unpack_fields()

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/41

into  sin.intern.azundris.com:/home/tnurnberg/27198/41-27198


sql/mysql_priv.h:
  Bug #27198: Error returns from time() are ignored
  
  manual merge
sql/sql_class.h:
  Bug #27198: Error returns from time() are ignored
  
  manual merge

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

gettimeofday() can fail and presumably, so can time().
Keep an eye on it.

Since we have no data on this at all so far, we just
retry on failure (and log the event), assuming that
this is just an intermittant failure. This might of
course hang the threat until we succeed. Once we know
more about these failures, an appropriate more clever
scheme may be picked (only try so many times per thread,
etc., if that fails, return last "good" time() we got or
some such).  Using sql_print_information() to log as this
probably only occurs in high load scenarios where the debug-
trace likely is disabled (or might interfere with testing
the effect).  No test-case as this is a non-deterministic
issue.


sql/mysql_priv.h:
  Bug#27198: Error returns from time() are ignored
  
  move declarations for log.cc to before inclusion of
  sql_class.h as we now use sql_print_information() in
  there.
sql/sql_class.h:
  Bug#27198: Error returns from time() are ignored
  
  gettimeofday() can fail and presumably, so can time().
  Keep an eye on it.

into  sita.local:/Users/tsmith/m/bk/maint/41

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

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

into  gleb.loc:/home/uchum/work/bk/4.1-opt

into  sita.local:/Users/tsmith/m/bk/maint/41

into  anubis.xiphis.org:/usr/home/antony/work/mysql-4.1-engines.merge

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

Dropping an user defined function may cause server crash in
case this function is still in use by another thread.

The problem was that our hash implementation didn't update
hash link list properly when hash_update() was called.


mysys/hash.c:
  The following requirement wasn't met by hash_update() function
  causing corruption of hash links list:
  
  After a record was unlinked from the old chain during update, it
  holds random position. By the chance this position is equal to
  position for the first element in the new chain. That means
  updated record is the only record in the new chain.

into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/41

into  gleb.loc:/home/uchum/work/bk/4.1-opt

  Test case update for bug #29294.


mysql-test/t/loaddata.test:
  Test case update for bug #29294.
mysql-test/r/loaddata.result:
  Test case update for bug #29294.

  Windows compilation error fix.


sql/sql_class.cc:
  Windows compilation error fix.

The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
encoded the 'r' string to a 4 byte string of value x'725c7272'
(sequence of 4 characters: r\rr).
The LOAD DATA statement decoded this string to a 1 byte string of
value x'0d' (ASCII Carriage Return character) instead of the original
'r' character.
The same error also happened with the FIELDS ENCLOSED BY clause
followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.

NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
recognises 2-byte input sequences like \n, \t, \r and \Z in addition
to documented 2-byte sequences: \0 and \N. This feature should be
documented (here backspace character is a default ESCAPED BY character,
in the real-life example it may be any ESCAPED BY character).

NOTE 2, changed behaviour:
Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
encodes this special character itself by doubling it ('r' --> 'rr'),
not by prepending it with an escape character.


sql/sql_class.h:
  Fixed bug #29294.
  The ESCAPE_CHARS macro constant is defined to enumerate
  symbolic names of espace-sequences like  '\n', '\t' etc.
  The select_export::is_ambiguous_field_sep field has been added
  to distinguish special values of the field_sep field from
  another values (see ESCAPE_CHARS).
sql/sql_class.cc:
  Fixed bug #29294.
  The select_export::send_data method has been modified to
  encode special values of the field_sep field by
  doubling of those values instead of prepending them with a
  value of the escape_char field.
  Example: The SELECT 'r' INTO OUTFILE FIELDS ENCLOSED BY 'r'
  now produces the 'rr' output string instead of x'5c72'
  (i.e. instead of sequence of 2 bytes: \ and r).
sql/sql_load.cc:
  Fixed bug #29294.
  Added commentary for the READ_INFO::unescape method.
mysql-test/t/loaddata.test:
  Updated test case for bug #29294.
mysql-test/r/loaddata.result:
  Updated test case for bug #29294.

Sometimes special 0 ENUM values was ALTERed to normal
empty string ENUM values.

Special 0 ENUM value has the same string representation
as normal ENUM value defined as '' (empty string).
The do_field_string function was used to convert
ENUM data at an ALTER TABLE request, but this
function doesn't care about numerical "indices" of
ENUM values, i.e. do_field_string doesn't distinguish
a special 0 value from an empty string value.

A new copy function called do_field_enum has been added to
copy special 0 ENUM values without conversion to an empty
string.


sql/field_conv.cc:
  Fixed bug #29251.
  The Copy_field::get_copy_func method has been modified to
  return a pointer to the do_field_enum function if a conversion
  between two columns of incompatible enum types is required.
  The do_field_enum function has been added for the correct
  conversion of special 0 enum values.
mysql-test/t/type_enum.test:
  Updated test case for bug #29251.
mysql-test/r/type_enum.result:
  Updated test case for bug #29251.

into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/41

into  gleb.loc:/home/uchum/work/bk/4.1-opt

into  mysql.com:/home/ram/work/b29079/b29079.4.1

Problem: long and long long types mess in a comparison may lead to wrong results on some platforms.
Fix: prefer [unsigned] long long as [u]longlong as it's used unconditionally in many places.


include/my_global.h:
  Fix for bug #29079: Semantics of "bigint" depend on platform specifics (size, signedness of char ?)
    - use [unsigned] long long as [u]longlong if sizeof(long long) == 8, to avoid type mess,
      as we use [unsigned] long long unconditionally in many places, for example in constants 
      with [U]LL suffix.

into  magare.gmz:/home/kgeorge/mysql/autopush/B29116-4.1-opt

 counters from relay

Updated the test to return columns vertically.


mysql-test/r/rpl_change_master.result:
  Bug #29116: test updated
mysql-test/t/rpl_change_master.test:
  Bug #29116: test updated

into  pilot.(none):/data/msvensson/mysql/mysql-4.1-maint

 - Add test case for this already existing feature 


mysql-test/r/mysqltest.result:
  Update result file
mysql-test/t/mysqltest.test:
  Add test case for this feature

we use net->vio in my_net_local_init, but in the my_net_init
implementation we set it after the call, so work with unspecified
net->vio value


sql/net_serv.cc:
  Bug #29117 (init_file test crashes with embedded server)
  
  as we started using net->vio in my_net_local_init, we should set
  it before the call

into  maint1.mysql.com:/data/localhome/tsmith/bk/maint/41


configure.in:
  Auto merged

into  trift2.:/MySQL/M41/push-4.1

into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-4.1-build

into  trift2.:/MySQL/M41/push-4.1

into  trift2.:/MySQL/M41/push-4.1

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

into  trift2.:/MySQL/M41/push-4.1

into  mysql.com:/d2/hf/mrg/mysql-4.1-opt