The problem was that some facilities (like CONVERT_TZ() function or
server HELP statement) may require implicit access to some tables in
'mysql' database.  This access was done by ordinary means of adding
such tables to the list of tables the query is going to open.
However, if we issued LOCK TABLES before that, we would get "table
was not locked" error trying to open such implicit tables.

The solution is to treat certain tables as MySQL system tables, like
we already do for mysql.proc.  Such tables may be opened for reading
at any moment regardless of any locks in effect.  The cost of this is
that system table may be locked for writing only together with other
system tables, it is disallowed to lock system tables for writing and
have any other lock on any other table.

After this patch the following tables are treated as MySQL system
tables:
  mysql.help_category
  mysql.help_keyword
  mysql.help_relation
  mysql.help_topic
  mysql.proc (it already was)
  mysql.time_zone
  mysql.time_zone_leap_second
  mysql.time_zone_name
  mysql.time_zone_transition
  mysql.time_zone_transition_type

These tables are now opened with open_system_tables_for_read() and
closed with close_system_tables(), or one table may be opened with
open_system_table_for_update() and closed with close_thread_tables()
(the latter is used for mysql.proc table, which is updated as part of
normal MySQL server operation).  These functions may be used when
some tables were opened and locked already.

NOTE: online update of time zone tables is not possible during
replication, because there's no time zone cache flush neither on LOCK
TABLES, nor on FLUSH TABLES, so the master may serve stale time zone
data from cache, while on slave updated data will be loaded from the
time zone tables.

therefore the logic associated with it never worked.

wrapped by DBUG_ASSERT().

into  booka.opbmk:/home/alik/Documents/MySQL/devel/5.1-rt-im

Log messages from shell-scripts were put to var/log/<test id>.log
file. Now, this file is used by mysql-test-run.pl. So, move log
messages to var/log/<test id>.script.log.

into  alik.opbmk:/mnt/raid/alik/MySQL/devel/5.1-rt-build

'shutdown_delay' option name.

into  alik.opbmk:/mnt/raid/alik/MySQL/devel/5.1-rt-build

which accidentally got broken during the merge
on 16-Feb-2007.

into  alik.opbmk:/mnt/raid/alik/MySQL/devel/5.1-rt

Fix timeouts. Only test suite is changed.

into  alik.opbmk:/mnt/raid/alik/MySQL/devel/5.1-rt-merge

into  naruto.:C:/cpp/mysql-5.1-runtime

The cause of im_daemon_life_cycle.imtest random failures was the following
behaviour of some implementations of LINUX threads: let's suppose that a
process has several threads (in LINUX threads, there is a separate process for
each thread). When the main process gets killed, the parent receives SIGCHLD
before all threads (child processes) die. In other words, the parent receives
SIGCHLD, when its child is not completely dead.

In terms of IM, that means that IM-angel receives SIGCHLD when IM-main is not dead
and still holds some resources. After receiving SIGCHLD, IM-angel restarts
IM-main, but IM-main failed to initialize, because previous instance (copy) of
IM-main still holds server socket (TCP-port).

Another problem here was that IM-angel restarted IM-main only if it was killed
by signal. If it exited with error, IM-angel thought it's intended / graceful
shutdown and exited itself.

So, when the second instance of IM-main failed to initialize, IM-angel thought
it's intended shutdown and quit.

The fix is
  1. to change IM-angel so that it restarts IM-main if it exited with error code;
  2. to change IM-main so that it returns proper exit code in case of failure.

  1. use MySQL headers instead of system ones;
  2. move logical part of code into a separate function.

into  kpdesk.mysql.com:/home/thek/dev/mysql-5.1-runtime

into  kpdesk.mysql.com:/home/thek/dev/mysql-5.1-runtime

- Merged from 5.0
- Removed redundant call to set_time(); now included in init_for_queries

into  kpdesk.mysql.com:/home/thek/dev/mysql-5.0-runtime

into  kpdesk.mysql.com:/home/thek/dev/bug23240/my51-bug23240

- Starting time of a query sent by bootstrapping wasn't initialized
  and starting time defaulted to 0. This later used value by NOW-
  item and was translated to 1970-01-01 11:00:00.
- Marketing the time with thd->set_time() before the call to
  mysql_parse resolves this issue.
- set_time was refactored to be part of the thd->init_for_queries-
  process.

into  kpdesk.mysql.com:/home/thek/dev/bug23240/my50-bug23240

- Starting time of a query sent by file bootstrapping wasn't initialized
  and starting time defaulted to 0. This later used value by the Now-
  item and is translated to 1970-01-01 11:00:00.
- marking the time with thd->set_time() before the call to 
  mysql_parse resolves this issue.

im_daemon_life_cycle fails randomly.

1. Move IM-angel functionality into a separate file, create Angel class.
2. Be more verbose;
3. Fix typo in FLUSH INSTANCES implementation;
4. Polishing.

into  weblab.(none):/home/marcsql/TREE/mysql-5.0-rt-merge

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-rt-merge

- The condition variable implementation "lost" a signal to
  WaitOnSingleObject when a semaphore was released.
- The signal could be consumed by a new call to pthread_cond_wait
  before all waiting threads had awoken.
- The new implementation of pthread_cond_* uses events
  instead of semaphores. It also uses an extra lock to protect entry
  into new cond wait before the broadcast has finished.