duplicate fields removed, st_mysql_storage_engine added to support
run-time handlerton initialization (no compiler warnings), handler API
is now tied to MySQL version, handlerton->plugin mapping added
(slot-based), dummy default_hton removed, plugin-type-specific
initialization generalized, built-in plugins are now initialized too,
--default-storage-engine no longer needs a list of storage engines
in handle_options().
mysql-test-run.pl bugfixes
- Scheduler is either initialized at server start or never.
Starting & stopping is now suspending & resuming.
- The scheduler has clear OO interface
- Now all calls to the scheduler are synchronous
- GLOBAL event_scheduler uses thd::sys_var_tmp (see set_var.cc)
- External API is encapsulated into class Events
- Includes fixes for all comments of Kostja's review of 19.05.2005
Starting to merge into 5.1-release (5.1.10) and push
mysqldump / SHOW CREATE TABLE will show the NEXT available value for
the PK, rather than the *first* one that was available (that named in
the original CREATE TABLE ... AUTO_INCREMENT = ... statement).
This should produce correct and robust behaviour for the obvious use
cases -- when no data were inserted, then we'll produce a statement
featuring the same value the original CREATE TABLE had; if we dump
with values, INSERTing the values on the target machine should set the
correct next_ID anyway (and if not, we'll still have our AUTO_INCREMENT =
... to do that). Lastly, just the CREATE statement (with no data) for
a table that saw inserts would still result in a table that new values
could safely be inserted to).
There seems to be no robust way however to see whether the next_ID
field is > 1 because it was set to something else with CREATE TABLE
... AUTO_INCREMENT = ..., or because there is an AUTO_INCREMENT column
in the table (but no initial value was set with AUTO_INCREMENT = ...)
and then one or more rows were INSERTed, counting up next_ID. This
means that in both cases, we'll generate an AUTO_INCREMENT =
... clause in SHOW CREATE TABLE / mysqldump. As we also show info on,
say, charsets even if the user did not explicitly give that info in
their own CREATE TABLE, this shouldn't be an issue.
As per above, the next_ID will be affected by any INSERTs that have
taken place, though. This /should/ result in correct and robust
behaviour, but it may look non-intuitive to some users if they CREATE
TABLE ... AUTO_INCREMENT = 1000 and later (after some INSERTs) have
SHOW CREATE TABLE give them a different value (say, CREATE TABLE
... AUTO_INCREMENT = 1006), so the docs should possibly feature a
caveat to that effect.
It's not very intuitive the way it works now (with the fix), but it's
*correct*. We're not storing the original value anyway, if we wanted
that, we'd have to change on-disk representation?
If we do dump/load cycles with empty DBs, nothing will change. This
changeset includes an additional test case that proves that tables
with rows will create the same next_ID for AUTO_INCREMENT = ... across
dump/restore cycles.
Confirmed by support as likely solution for client's problem.
Added support for key_block_size to MyISAM.
Simplify interface to 'new Key' to make it easier to add new key options.
mysqld option --new is used to define where key options are printed.
(In 5.3 we should move all key options to after key part definition to avoid problem with reserved names)
Fixed some compiler warnings and a memory leak in ssl
Added missing DBUG_xxx_RETURN statements
Fixed some usage of not initialized variables (as found by valgrind)
Ensure that we don't remove locked tables used as name locks from open table cache until unlock_table_names() are called.
This was fixed by having drop_locked_name() returning any table used as a name lock so that we can free it in unlock_table_names()
This will allow Tomas to continue with his work to use namelocks to syncronize things.
Note: valgrind still produces a lot of warnings about using not initialized code and shows memory loss errors when running the ndb tests
Crash happened when one selected data from one of INFORMATION_SCHEMA
tables and in order to build its contents server had to open view which
used stored function and table or view on which one had not global or
database-level privileges (e.g. had only table-level or had no
privileges at all).
The crash was caused by usage of check_grant() function, which assumes
that either number of tables to be inspected by it is limited explicitly
or table list used and thd->lex->query_tables_own_last value correspond
to each other (the latter should be either 0 or point to next_global
member of one of elements of this table list), in conditions when
above assumptions were not true. This fix just explicitly limits
number of tables to be inspected. Other negative effects which are
caused by the fact that thd->lex->query_tables_own_last might not
be set properly during processing of I_S tables are less disastrous
and will be reported and fixed separetely.
