Faster thr_alarm()
Added 'Opened_files' status variable to track calls to my_open()
Don't give warnings when running mysql_install_db
Added option --source-install to mysql_install_db
I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
index_read() -> index_read_map()
index_read_idx() -> index_read_idx_map()
index_read_last() -> index_read_last_map()
Additional changes for bug#29903
- Changed to do embedded build part as normal build, when
WITH_EMBEDDED_SERVER is set.
- Allow both normal and debug build with embedded.
- Build static embedded library by pointing out all source and compile
it all, i.e. not building libraries from libraries, not portable.
- Let embedded use generated files from the "sql" directory, added
dependencies to make sure built before embedded.
- Mark library "dbug" in TARGET_LINK_LIBRARIES() with "debug", so only
linked in when debug target is used.
- Removed change of target name with "mysqld${MYSQLD_EXE_SUFFIX}", as
others can't depend on it, not defined at configure time. Instead
set the output file name.
- Created work around for bug in CMake 2.4.6 and output names, to
set the "mysqld<suffix>.pdb" name to the same base name.
- Set the correct manifest "name" (patch by iggy)
They had been introduced in 5.1 and were only later backported to 5.0;
as a consequence, the files in the 5.1 tree do not depend on the 5.0 ones,
and changes in 5.0 do not propagate into the 5.1 files.
To fix this, the (previous) files in 5.1 now are deleted ("bk rm"),
and the previously deleted files depending on 5.0 are now moved to the
respective source directories ("bk mv").
The current 5.1 contents is restored in these files.
If you need the previous history of the 5.1 files ("bk revtool"),
access those in "BitKeeper/deleted".
Contrary to the original plan, I did not introduce the name
"CMakeLists.historic" - mostly in order not to clutter the source tree.
This fixes bug#29982.
Bug#25422 (Hang with log tables)
Bug 17876 (Truncating mysql.slow_log in a SP after using cursor locks the
thread)
Bug 23044 (Warnings on flush of a log table)
Bug 29129 (Resetting general_log while the GLOBAL READ LOCK is set causes
a deadlock)
Prior to this fix, the server would hang when performing concurrent
ALTER TABLE or TRUNCATE TABLE statements against the LOG TABLES,
which are mysql.general_log and mysql.slow_log.
The root cause traces to the following code:
in sql_base.cc, open_table()
if (table->in_use != thd)
{
/* wait_for_condition will unlock LOCK_open for us */
wait_for_condition(thd, &LOCK_open, &COND_refresh);
}
The problem with this code is that the current implementation of the
LOGGER creates 'fake' THD objects, like
- Log_to_csv_event_handler::general_log_thd
- Log_to_csv_event_handler::slow_log_thd
which are not associated to a real thread running in the server,
so that waiting for these non-existing threads to release table locks
cause the dead lock.
In general, the design of Log_to_csv_event_handler does not fit into the
general architecture of the server, so that the concept of general_log_thd
and slow_log_thd has to be abandoned:
- this implementation does not work with table locking
- it will not work with commands like SHOW PROCESSLIST
- having the log tables always opened does not integrate well with DDL
operations / FLUSH TABLES / SET GLOBAL READ_ONLY
With this patch, the fundamental design of the LOGGER has been changed to:
- always open and close a log table when writing a log
- remove totally the usage of fake THD objects
- clarify how locking of log tables is implemented in general.
See WL#3984 for details related to the new locking design.
Additional changes (misc bugs exposed and fixed):
1)
mysqldump which would ignore some tables in dump_all_tables_in_db(),
but forget to ignore the same in dump_all_views_in_db().
2)
mysqldump would also issue an empty "LOCK TABLE" command when all the tables
to lock are to be ignored (numrows == 0), instead of not issuing the query.
3)
Internal errors handlers could intercept errors but not warnings
(see sql_error.cc).
4)
Implementing a nested call to open tables, for the performance schema tables,
exposed an existing bug in remove_table_from_cache(), which would perform:
in_use->some_tables_deleted=1;
against another thread, without any consideration about thread locking.
This call inside remove_table_from_cache() was not required anyway,
since calling mysql_lock_abort() takes care of aborting -- cleanly -- threads
that might hold a lock on a table.
This line (in_use->some_tables_deleted=1) has been removed.
