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

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

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

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

into  production.mysql.com:/usersnfs/jperkin/bk/mysql-4.1-maint

which does not work.  Removing these attempted privileges makes
this identical to option 5 so remove it completely.  The spirit
of the program appears to be aimed at database privileges, so do
not add another option for granting global privileges as it may
be unexpected.  Fixes bug#14618 (same as previous patch, this
time applied to -maint tree).


scripts/mysql_setpermission.sh:
  Option 6 tries to apply global privileges at the database
  level which does not work - remove it.

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/29717/my41-29717


sql/sql_select.cc:
  Auto merged

 SELECT statement itself returns empty.

As a result of this bug 'SELECT AGGREGATE_FUNCTION(fld) ... GROUP BY'
can return one row instead of an empty result set.

When GROUP BY only has fields of constant tables
(with a single row), the optimizer deletes the group_list.
After that we lose the information about whether we had an
GROUP BY statement. Though it's important
as SELECT min(x) from empty_table; and
   SELECT min(x) from empty_table GROUP BY y; have to return
different results - the first query should return one row,
second - an empty result set.
So here we add the 'group_optimized_away' flag to remember this case
when GROUP BY exists in the query and is removed
by the optimizer, and check this flag in end_send_group()


mysql-test/r/group_by.result:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  test result
mysql-test/r/insert_select.result:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  test result
mysql-test/t/group_by.test:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  This is additional testcase that is more basic than the
  original bug's testcase and has the same reason.
mysql-test/t/insert_select.test:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  test case
sql/sql_select.cc:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  Remember the 'GROUP BY was optimized away' case in the JOIN::group_optimized
  and check this in the end_send_group()
sql/sql_select.h:
  Bug #29717 INSERT INTO SELECT inserts values even if
   SELECT statement itself returns empty.
  
  JOIN::group_optimized member added to remember the 'GROUP BY optimied away'
  case

  Backport of correction for Mac OS X build problem, global variable not
  initiated is "common" and can't be used in shared libraries, unless
  special flags are used (bug#26218)


mysys/my_pthread.c:
  Backport of correction for Mac OS X build problem, global variable not
  initiated is "common" and can't be used in shared libraries, unless
  special flags are used (bug#26218)

into  debian.(none):/M41/push-4.1

to 150 or 107 characters for those messages which are generated
by the embedded server during release builds.

This fixes bug#16635:
   Error messages wrong: absolute path names, "%s" format code

See the bug report or the changelog for "sql/share/english/errmsg.txt"
for instructions how to do that with other languages, 
even at the customer site, and for the restrictions to keep.


sql/share/english/errmsg.txt:
  The embedded server uses absolute path names in its error messages,
  in the release build environment these exceed the 64 character limit
  which the format strings for the error messages impose (bug#16635).
  
  But when the messages are output, the server does the "printf()" 
  internally in a 256 character buffer; the constant text and the
  expanded variables (strings, error number) must fit into this.
  
  (If the buffer would overflow, a format specification will not be
  expanded but just copied with its code, and the message output
  will just contain '%s' or '%d' where a value is expected.)
  
  So the string lengths are increased to 150 characters in those messages
  which are issued by the embedded server during release tests
  and contain 1 (one) path name,
  but only to 107 in the "rename" message which contains 2 (two).
  
  This solves bug#16635 for the release builds.
  
  For other languages used by OEM customers, similar fixes may be needed,
  but we cannot test them.
  
  These fixes can be done even in a binary installation at the customer site
  by following these steps:
     cd <<install-root>>/share
     $EDITOR <<lang>>/errmsg.txt
     ../../bin/comp_err -C./charsets/ <<lang>>/errmsg.txt <<lang>>/errmsg.sys
  and then restarting the server.

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