Allow for configuration of the maximum number of indexes per table.
Added and used a configure.in macro.
Replaced fixed limits by the configurable limit.
Limited MyISAM indexes to its hard limit.
Fixed a bug in opt_range.cc for many indexes with InnoDB.
Tested for 2, 63, 64, 65, 127, 128, 129, 255, 256, and 257 indexes.
Testing this part of the bugfix requires rebuilding of the server
with different options. This cannot be done with our test suite.
Therefore I added the necessary test files to the bug report.
If you repeat the tests, please note that the ps_* tests fail for
everything but 64 indexes. This is because of differences in the
meta data, namely field lengths for index names etc.
Post-review fixes that simplify the way access rights
are checked during name resolution and factor out all
entry points to check access rights into one single
function.
CREATE TABLE and PS/SP": make sure that 'typelib' object for
ENUM values and 'Item_string' object for DEFAULT clause are
created in the statement memory root.
The table opening process now works the following way:
- Create common TABLE_SHARE object
- Read the .frm file and unpack it into the TABLE_SHARE object
- Create a TABLE object based on the information in the TABLE_SHARE
object and open a handler to the table object
Other noteworthy changes:
- In TABLE_SHARE the most common strings are now LEX_STRING's
- Better error message when table is not found
- Variable table_cache is now renamed 'table_open_cache'
- New variable 'table_definition_cache' that is the number of table defintions that will be cached
- strxnmov() calls are now fixed to avoid overflows
- strxnmov() will now always add one end \0 to result
- engine objects are now created with a TABLE_SHARE object instead of a TABLE object.
- After creating a field object one must call field->init(table) before using it
- For a busy system this change will give you:
- Less memory usage for table object
- Faster opening of tables (if it's has been in use or is in table definition cache)
- Allow you to cache many table definitions objects
- Faster drop of table
into mysql.com:/home/mysql_src/mysql-5.1-merge-of-5.0
(2nd try; Pekka kindly accepted to fix storage/ndb/src/kernel/blocks/dbtup/DbtupRoutines.cpp
and storage/ndb/src/kernel/vm/SimulatedBlock.cpp after I push).
Version for 5.0.
It fixes three problems:
1. The cause of the bug was that we did not check the table version for
the HANDLER ... READ commands. We did not notice when a table was
replaced by a new one. This can happen during ALTER TABLE, REPAIR
TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix
for this problem "the primary bug fix".
2. mysql_ha_flush() was not always called with a locked LOCK_open.
Though the function comment clearly said it must.
I changed the code so that the locking is done when required. I call
the fix for this problem "the secondary fix".
3. In 5.0 (not in 4.1 or 4.0) DROP TABLE had a possible deadlock flaw in
concur with FLUSH TABLES WITH READ LOCK. I call the fix for this
problem "the 5.0 addendum fix".
Indeed now that stored procedures CALL is not binlogged, but instead the invoked substatements are,
the restrictions applied by log-bin-trust-routine-creators=0 are superfluous for procedures.
They still need to apply to functions where function calls are written to the binlog (for example as "DO myfunc(3)").
We rename the variable to log-bin-trust-function-creators but allow the old name until some future version (and issue a warning if old name is used).
- removed some returns on ndb internal error codes, return ndb cause in warnings
- moved all errorcode mapping mysqld-ndb to ndberror.c
- ndb util thread to discover all ndb tables at startup
- ndb util thread to wait for mysqld startup
Version for 4.0.
It fixes two problems:
1. The cause of the bug was that we did not check the table version for
the HANDLER ... READ commands. We did not notice when a table was
replaced by a new one. This can happen during ALTER TABLE, REPAIR
TABLE, and OPTIMIZE TABLE (there might be more cases). I call the fix
for this problem "the primary bug fix".
2. mysql_ha_flush() was not always called with a locked LOCK_open.
Though the function comment clearly said it must.
I changed the code so that the locking is done when required. I call
the fix for this problem "the secondary fix".
droping trigger on InnoDB table".
Deadlock occured in cases when we were trying to create two triggers for
the same InnoDB table concurrently and both threads were able to reach
close_cached_table() simultaneously. Bugfix implements new approach to
table locking and table cache invalidation during creation/dropping
of trigger.
No testcase is supplied since bug was repeatable only under high concurrency.
Some options were declared as 'bool', but since those are being
handled in my_getopt.c, bool can be machine dependent. To make
sure it works in all circumstances, the type should be my_bool
for C (not C++) programs.
Handlerton array is now created instead of using sys_table_types_st. All storage engines can now have inits and giant ifdef's are now gone for startup. No compeltely clean yet, handlertons will next be merged with sys_table_types. Federated and archive now have real cleanup if their inits fail.
This bug occurs when some trigger for table used by DML statement is created
or changed while statement was waiting in lock_tables(). In this situation
prelocking set which we have calculated becames invalid which can easily lead
to errors and even in some cases to crashes.
With proposed patch we no longer silently reopen tables in lock_tables(),
instead caller of lock_tables() becomes responsible for reopening tables and
recalculation of prelocking set.
present): the problem originally was that the tables in auxilliary_tables did not have
the correct real_name, which caused problems in the second call to tables_ok().
The fix corrects the real_name problem, and also sets the updating flag properly,
which makes the second call to tables_ok() unnecessary.
Information_schema DB
Bug#9846 Inappropriate error displayed while
dropping table from 'INFORMATION_SCHEMA'
Bug#10734 Grant of privileges other than 'select' and
'create view' should fail on schema
Bug#10708 SP's can use INFORMATION_SCHEMA as ROUTINE_SCHEMA
cumulative fix for bugs above(after review, 2nd version)
added privilege check for information schema db & tables
The idea of the patch is to separate statement processing logic,
such as parsing, validation of the parsed tree, execution and cleanup,
from global query processing logic, such as logging, resetting
priorities of a thread, resetting stored procedure cache, resetting
thread count of errors and warnings.
This makes PREPARE and EXECUTE behave similarly to the rest of SQL
statements and allows their use in stored procedures.
This patch contains a change in behaviour:
until recently for each SQL prepared statement command, 2 queries
were written to the general log, e.g.
[Query] prepare stmt from @stmt_text;
[Prepare] select * from t1 <-- contents of @stmt_text
The chagne was necessary to prevent [Prepare] commands from being written
to the general log when executing a stored procedure with Dynamic SQL.
We should consider whether the old behavior is preferrable and probably
restore it.
This patch refixes Bug#7115, Bug#10975 (partially), Bug#10605 (various bugs
in Dynamic SQL reported before it was disabled).
- current_arena to stmt_arena: the thread may have more than one
'current' arenas: one for runtime data, and one for the parsed
tree of a statement. Only one of them is active at any moment.
- set_item_arena -> set_query_arena, because Item_arena was renamed to
Query_arena a while ago
- set_n_backup_item_arena -> set_n_backup_active_arena;
the active arena is the arena thd->mem_root and thd->free_list
are currently pointing at.
- restore_backup_item_arena -> restore_active_arena (with the same
rationale)
- change_arena_if_needed -> activate_stmt_arena_if_needed; this
method sets thd->stmt_arena active if it's not done yet.
"Interleaved SPs execution is now binlogged properly, "SELECT spfunc()" is binlogged too.
The known remaining issue is binlogging/replication of "a routine is deleted while it is executed" scenario.
"Process NATURAL and USING joins according to SQL:2003".
* Some of the main problems fixed by the patch:
- in "select *" queries the * expanded correctly according to
ANSI for arbitrary natural/using joins
- natural/using joins are correctly transformed into JOIN ... ON
for any number/nesting of the joins.
- column references are correctly resolved against natural joins
of any nesting and combined with arbitrary other joins.
* This patch also contains a fix for name resolution of items
inside the ON condition of JOIN ... ON - in this case items must
be resolved only against the JOIN operands. To support such
'local' name resolution, the patch introduces a stack of
name resolution contexts used at parse time.
NOTICE:
- This patch is not complete in the sense that
- there are 2 test cases that still do not pass -
one in join.test, one in select.test. Both are marked
with a comment "TODO: WL#2486".
- it does not include a new test specific for the task
result set".
To enable full access to contents of I_S tables from stored functions
or statements that use them, we manipulate with thread's open tables
state and ensure that we won't cause deadlock when we open tables by
ignoring flushes and name-locks.
Building of contents of I_S.TABLES no longer requires locking of tables
since we use use handler::info() method with HA_STATUS_AUTO flag instead
of handler::update_auto_increment() for obtaining information about
auto-increment values. But this also means that handlers have to implement
support for HA_STATUS_AUTO flag (particularly InnoDB needs it).
When creating temporary table for UNION, pass TMP_TABLE_FORCE_MYISAM flag to
create_tmp_table if we will be using fulltext function(s) when reading from the
temp. table.
Fixed bug #12154: a query returned: Column <name> cannot be null.
The problem was due to a bug in the function setup_table_map:
the flag maybe_null was set up incorrectly for inner tables of
nested outer joins.
join_nested.result, join_nested.test:
Added a test case for bug #12154.
Change bool in C code to my_bool
Added to mysqltest --enable_parsning and --disable_parsing to avoid to have to comment parts of tests
Added comparison of LEX_STRING's and use this to compare file types for view and trigger files.
Fixed portability problem with bool in C programs
Moved close_thread_tables out from LOCK_thread_count mutex (safety fix)
my_sleep() -> pthread_cond_timedwait()
"Triggers have the wrong namespace"
"Triggers: duplicate names allowed"
"Triggers: CREATE TRIGGER does not accept fully qualified names"
"SHOW TRIGGERS"
of system vars at PREPARE time": implement a special Item
to handle system variables. This item substitutes itself with
a basic constant containing variable value at fix_fields.
data": remove the fix for another bug (8807) that
added OUTER_REF_TABLE_BIT to all subqueries that used a placeholder
to prevent their evaluation at prepare. As this bit hanged in
Item_subselect::used_tables_cache for ever, a constant subquery with
a placeholder was never evaluated as such, which caused wrong
choice of the execution plan for the statement.
- to fix Bug#8807 backport a better fix from 5.0
- post-review fixes.
of stored routines definitions even if we already have some tables open and
locked. To avoid deadlocks in this case we have to put certain restrictions
on locking of mysql.proc table.
This allows to use stored routines safely under LOCK TABLES without explicitly
mentioning mysql.proc in the list of locked tables. It also fixes bug #11554
"Server crashes on statement indirectly using non-cached function".
bug #10617: Insert from same table to same table give incorrect result for bit(4) column.
bug #11091: union involving BIT: assertion failure in Item::tmp_table_field_from_field_type
bug #11572: MYSQL_TYPE_BIT not taken care of in temp. table creation for VIEWs
#9728 'Decreased functionality in "on duplicate key update
#8147 'a column proclaimed ambigous in INSERT ... SELECT .. ON DUPLICATE'
This ensures fields are uniquely qualified and also that one can't update other tables in the ON DUPLICATE KEY UPDATE part
Bug#8367 "low log doesn't gives complete information about prepared
statements"
Implement status variables for prepared statements commands (a port of
the patch by Andrey Hristov).
See details in comments to the changed files.
No test case as there is no way to test slow log/general log in
mysqltest.
ALTER, OPTIMIZE and ANALYZE statements".
In 4.1 we disabled logging of slow admin statements. The fix adds an
option to enable it back.
No test case (slow log is not tested in the test suite), but tested
manually.
+ post-review fixes (word police mainly).
CURSOR_TYPE_READ_ONLY". The bug was that we (me) don't perform proper
cleanups of the prepared statement when done fetching from a cursor.
Another patch.
In order to make multi-delete SP friendly we need to have all table
locks for the elements of main statement table list properly set
at the end of parsing.
Also performed small cleanup: We don't need relink_tables_for_multidelete()
any longer since the only case now when TABLE_LIST::correspondent_table
is non-zero are tables in auxilary table list of multi-delete and these
tables are handled specially in mysql_multi_delete_prepare().
UPPER/LOWER now can return a string with different length.
mi_test1.c:
Adding new arguments.
Many files:
Changeing caseup/casedn to return a result with different
length than argument.
sql_string.h:
Removing unused method,
mysql_priv.h:
Removing unused method
Simple optimization for 2 argument usage to function of variable arguments
Fix stack overrun when using 1+1+1+1+1+1+1+....
Update crash-me results for 5.0
Don't call post_open if pre_open() fails (optimization)
Ensure that 'null_value' is not accessed before val() is called in FIELD() functions
Fixed initialization of key maps. This fixes some problems with keys when you have more than 64 keys
Fixed that ROLLUP don't always create a temporary table. This fix ensures that func_gconcat.test results are now predictable
1.) Added a new option to mysql_lock_tables() for ignoring FLUSH TABLES.
Used the new option in create_table_from_items().
It is necessary to prevent the SELECT table from being reopend.
It would get new storage assigned for its fields, while the
SELECT part of the command would still use the old (freed) storage.
2.) Protected the CREATE TABLE and CREATE TABLE ... SELECT commands
against a global read lock. This prevents a deadlock in
CREATE TABLE ... SELECT in conjunction with FLUSH TABLES WITH READ LOCK
and avoids the creation of new tables during a global read lock.
3.) Replaced set_protect_against_global_read_lock() and
unset_protect_against_global_read_lock() by
wait_if_global_read_lock() and start_waiting_global_read_lock()
in the INSERT DELAYED handling.
"the server side preparedStatement error for LIMIT placeholder",
which moves all uses of LIMIT clause from PREPARE to OPTIMIZE
and later steps.
After-review fixes.
This only showed up on two known platforms, both ia64 (one HP-UX and one Linux wich icc).
For some reason, they only get half the stack size they are supposed to have, which
makes deep SP recursion overrun the stack before check_stack_overrun() is triggered.
Also made som minor fixes in the check_stack_overrun() definition, supporting variable
margins.
No test case added, but the reason for the bug report was a failed existing test case
on these machines, which now works.
- Dont perform automatic privilege handling for stored procedures when server is started --skip-grant-tables
- Renamed view_skip_grants to skip_grants and added test cases for this
#5860 "Multi-table UPDATE does not activate update triggers"
#6812 "Triggers are not activated for INSERT ... SELECT"
#8755 "Trigger is not activated by LOAD DATA".
This patch also implements proper handling of triggers for special forms
of insert like REPLACE or INSERT ... ON DUPLICATE KEY UPDATE.
Also now we don't call after trigger in case when we have failed to
inserted/update or delete row. Trigger failure should stop statement
execution.
I have not properly tested handling of errors which happen inside of
triggers in this patch, since it is simplier to do this once we will be
able to access tables from triggers.
