RENAME TABLE against a table with DATA/INDEX DIRECTORY overwrites
the file to which the symlink points.

This is security issue, because it is possible to create a table with
some name in some non-system database and set DATA/INDEX DIRECTORY
to mysql system database. Renaming this table to one of mysql system
tables (e.g. user, host) would overwrite the system table.

Return an error when the file to which the symlink points exist.

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.

  Updated to version 0.6 of the text

  Added test for sched_yield() possibly in -lposix4 on Solaris

  Removed unused files
.del-my_winsem.c:
  Delete: mysys/my_winsem.c
.del-my_semaphore.c:
  Delete: mysys/my_semaphore.c
.del-my_semaphore.h:
  Delete: include/my_semaphore.h

into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg0306/40

into  mysql.com:/home/kent/bk/tmp/mysql-4.0

into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/40

  EXCEPTIONS-CLIENT is now static part of repository

  EXCEPTIONS-CLIENT is now static part of repository
EXCEPTIONS-CLIENT:
  BitKeeper file /home/kent/bk/tmp/mysql-4.0/EXCEPTIONS-CLIENT

into  trift2.:/MySQL/M40/mysql-4.0

Companion change to this one
   ChangeSet@1.2206, 2007-01-22 02:32:07+02:00, jani@a88-113-38-195.elisa-laajakaista.fi +8 -0
     include/my_pthread.h@1.67, 2007-01-22 02:32:06+02:00, jani@a88-113-38-195.elisa-laajakaista.fi +31 -10
which renamed "sigset()" -> "my_sigset()" but forgot to do it for Windows ...

into  siva.hindu.god:/home/tsmith/m/bk/maint/40

Break a double declare of "uint thr_client_alarm" between "mysys/thr_alarm.c" and "mysys/my_pthread.c".

same fix from 4.0.

into  siva.hindu.god:/home/tsmith/m/bk/maint/40

into  production.mysql.com:/usersnfs/jamppa/mysql-4.0

Move get_thread_lib to mysys/my_pthread.c
Set 'thr_client_alarm' to signal number used by thr_alarm to give alarms

Move get_thread_lib to mysys/my_pthread.c
Set 'thr_client_alarm' to signal number used by thr_alarm to give alarms

Fix to check library in use during runtime.
Fix for Bug#16995, "idle connections not being killed due to timeout when NPTL is used".

into  siva.hindu.god:/home/tsmith/m/bk/mrg-jan17/maint/40

into  trift2.:/MySQL/M40/mysql-4.0

into  mysql.com:/data0/mysqldev/my/mysql-4.0-15815

into  trift2.:/MySQL/M40/mysql-4.0

into  kpdesk.mysql.com:/home/thek/dev/mysql-4.0-maint

into  quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/g40

no future build of it will include Berkeley DB:
Remove it from the Windows VC++ project files.

into  kpdesk.mysql.com:/home/thek/dev/mysql-4.0

into  moonlight.home:/home/tomash/src/mysql_ab/mysql-4.0-bug23443

           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.

- "make_binary_distribution" accepts a dummy "--platform=" argument.

- "MySQL-shared-compat.spec" uses a "version40" define symbol internally.

- Bug #15815: Very poor performance with multiple queries running concurrently
- Bug #22868: 'Thread thrashing' with > 50 concurrent conns under an upd-intensive workloadw

This is a patch from an e-mail; it is not included in an InnoDB snapshot.