server

The problem was that when memory was exhausted HEAP engine could crash
(GROUP BY uses HEAP TABLE).  Alternatively, if SET was used, it could
report an error "You may only use constant expressions with SET" instead
of "Out of memory (Needed NNNNNN bytes)".

The solution is:
 - pass MY_WME to (some) calls to my_malloc() to get correct message.
 - fix heap_write() so that the first key is skipped during cleanup
   on ENOMEM because it wasn't inserted and doesn't have to be
   deleted.

No test case is provided because we can't test out-of-memory behaviour
in our current test framework.

into  chilla.local:/home/mydev/mysql-4.0-bug20719

Deletes on a big index could crash the index when it needs to
shrink.

Put a forgotten negation operator in.

No test case. It is too big for the test suite. And it does not
work with 4.0, only with higher versions. It is attached to the
bug report.

into  chilla.local:/home/mydev/mysql-4.0-bug20719

            "concurrent insert"
After merge fix.

into  chilla.local:/home/mydev/mysql-4.0-bug14400

into  chilla.local:/home/mydev/mysql-4.0-bug14400

            "concurrent insert"
Additional fix for full keys and test case.

            subject of "concurrent insert"
Better fix by Monty: "The previous bug fix didn't work
when using partial keys."

Better bug fix for #14400 "Query joins wrong rows from table which is subject of "concurrent insert""
The previous bug fix didn't work when using partial keys.
Don't use GNUC min/max operations are they are depricated.
Fixed valgrind warning

  Corrected typo

  Man page for mysqld command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

  Man page for "mysqld" command move to section 8 (bug#21220)

  Filter out strange control characters, messes up logs

Fixed a possible problem with reading of dynamic records
when a write cache is active. The cache must be flushed
whenever a part of the file in the write cache is to be 
read.

Added a read optimization to _mi_read_dynamic_record().

No test case. This was a hypothetical but existing problem.

into  chilla.local:/home/mydev/mysql-4.0-bug14400

into  maint1.mysql.com:/data/localhome/cmiller/mysql-4.0__bug19006

have a better test (and so this should be null-merged there).

ALSO!  Make it so that it accepts NPTL as a valid _equivalent_ implementation.

On exactly-sized Strings, the String::c_ptr() function peeked beyond the
end of the buffer, possibly into unititialized space to see whether the 
buffer was NUL-terminated.

In a place that did peek improperly, we now use a c_ptr_safe() function, 
which doesn't peek where it shouldn't.

It was possible that fetching a record by an exact key value 
(including the record pointer) could return a record with a 
different key value. This happened only if a concurrent insert 
added a record with the searched key value after the fetching 
statement locked the table for read.

The search succeded on the key value, but the record was
rejected as it was past the file length that was remembered
at start of the fetching statement. With other words it was 
rejected as being a concurrently inserted record.

The action to recover from this problem was to fetch the 
record that is pointed at by the next key of the index. 
This was repeated until a record below the file length was 
found.

I do now avoid this loop if an exact match was searched. 
If this match is beyond the file length, it is now treated 
as "key not found". There cannot be another key with the 
same record pointer.

  For compatibility, don't use {..,..} in pattern matching
make_binary_distribution.sh:
  Added .dylib and .sl as shared library extensions

  Always compile position independent

  Change mode to -rw-rw-r--
dbug_add_tags.pl:
  Change mode to -rwxrwxr--

  Stepped up to 4.0.28

into  mysql.com:/home/mydev/mysql-4.0-bug10405

  Delete: Docs/changelog-4.0.xml

(based on the fact that packet is ALWAYS \0 terminated, see my_net_read)

(reported by Stefano Di Paola)

into  mysql.com:/home/mydev/mysql-4.0-bug5390

into  sanja.is.com.ua:/home/bell/mysql/bk/work-4.0

into  mysql.com:/usr/home/ram/work/mysql-4.0

into  sanja.is.com.ua:/home/bell/mysql/bk/work-4.0

code. (Bug #13621)

Whenever 'myisamchk' needed to recreate a table,
the auto increment information was lost.

Now the forgotten element of the table creation
information is set correctly.