the lexer API which internally uses unsigned char variables to
address its state map. The implementation of the lexer should be
internal to the lexer, and not influence the rest of the code.
fixes).
The legend: on a replication slave, in case a trigger creation
was filtered out because of application of replicate-do-table/
replicate-ignore-table rule, the parsed definition of a trigger was not
cleaned up properly. LEX::sphead member was left around and leaked
memory. Until the actual implementation of support of
replicate-ignore-table rules for triggers by the patch for Bug 24478 it
was never the case that "case SQLCOM_CREATE_TRIGGER"
was not executed once a trigger was parsed,
so the deletion of lex->sphead there worked and the memory did not leak.
The fix:
The real cause of the bug is that there is no 1 or 2 places where
we can clean up the main LEX after parse. And the reason we
can not have just one or two places where we clean up the LEX is
asymmetric behaviour of MYSQLparse in case of success or error.
One of the root causes of this behaviour is the code in Item::Item()
constructor. There, a newly created item adds itself to THD::free_list
- a single-linked list of Items used in a statement. Yuck. This code
is unaware that we may have more than one statement active at a time,
and always assumes that the free_list of the current statement is
located in THD::free_list. One day we need to be able to explicitly
allocate an item in a given Query_arena.
Thus, when parsing a definition of a stored procedure, like
CREATE PROCEDURE p1() BEGIN SELECT a FROM t1; SELECT b FROM t1; END;
we actually need to reset THD::mem_root, THD::free_list and THD::lex
to parse the nested procedure statement (SELECT *).
The actual reset and restore is implemented in semantic actions
attached to sp_proc_stmt grammar rule.
The problem is that in case of a parsing error inside a nested statement
Bison generated parser would abort immediately, without executing the
restore part of the semantic action. This would leave THD in an
in-the-middle-of-parsing state.
This is why we couldn't have had a single place where we clean up the LEX
after MYSQLparse - in case of an error we needed to do a clean up
immediately, in case of success a clean up could have been delayed.
This left the door open for a memory leak.
One of the following possibilities were considered when working on a fix:
- patch the replication logic to do the clean up. Rejected
as breaks module borders, replication code should not need to know the
gory details of clean up procedure after CREATE TRIGGER.
- wrap MYSQLparse with a function that would do a clean up.
Rejected as ideally we should fix the problem when it happens, not
adjust for it outside of the problematic code.
- make sure MYSQLparse cleans up after itself by invoking the clean up
functionality in the appropriate places before return. Implemented in
this patch.
- use %destructor rule for sp_proc_stmt to restore THD - cleaner
than the prevoius approach, but rejected
because needs a careful analysis of the side effects, and this patch is
for 5.0, and long term we need to use the next alternative anyway
- make sure that sp_proc_stmt doesn't juggle with THD - this is a
large work that will affect many modules.
Cleanup: move main_lex and main_mem_root from Statement to its
only two descendants Prepared_statement and THD. This ensures that
when a Statement instance was created for purposes of statement backup,
we do not involve LEX constructor/destructor, which is fairly expensive.
In order to track that the transformation produces equivalent
functionality please check the respective constructors and destructors
of Statement, Prepared_statement and THD - these members were
used only there.
This cleanup is unrelated to the patch.
Problem: DROP TRIGGER was not properly handled in combination
with slave filters, which made replication stop
Fix: loading table name before checking slave filters when
dropping a trigger.
- Removed not used variables and functions
- Added #ifdef around code that is not used
- Renamed variables and functions to avoid conflicts
- Removed some not used arguments
Fixed some class/struct warnings in ndb
Added define IS_LONGDATA() to simplify code in libmysql.c
I did run gcov on the changes and added 'purecov' comments on almost all lines that was not just variable name changes
Fixed compiler warnings (detected by VC++):
- Removed not used variables
- Added casts
- Fixed wrong assignments to bool
- Fixed wrong calls with bool arguments
- Added missing argument to store(longlong), which caused wrong store method to be called.
- Removed not used variables
- Changed some ulong parameters/variables to ulonglong (possible serious bug)
- Added casts to get rid of safe assignment from longlong to long (and similar)
- Added casts to function parameters
- Fixed signed/unsigned compares
- Added some constructores to structures
- Removed some not portable constructs
Better fix for bug Bug #21428 "skipped 9 bytes from file: socket (3)" on "mysqladmin shutdown"
(Added new parameter to net_clear() to define when we want the communication buffer to be emptied)
Added missing DBUG_RETURN statements (in mysqldump.c)
Added missing enums
Fixed a lot of wrong DBUG_PRINT() statements, some of which could cause crashes
Removed usage of %lld and %p in printf strings as these are not portable or produces different results on different systems.
This change set implements the DROP TRIGGER IF EXISTS functionality.
This fix is considered a bug and not a feature, because without it,
there is no known method to write a database creation script that can create
a trigger without failing, when executed on a database that may or may not
contain already a trigger of the same name.
Implementing this functionality closes an orthogonality gap between triggers
and stored procedures / stored functions (which do support the DROP IF
EXISTS syntax).
In sql_trigger.cc, in mysql_create_or_drop_trigger,
the code has been reordered to:
- perform the tests that do not depend on the file system (access()),
- get the locks (wait_if_global_read_lock, LOCK_open)
- call access()
- perform the operation
- write to the binlog
- unlock (LOCK_open, start_waiting_global_read_lock)
This is to ensure that all the code that depends on the presence of the
trigger file is executed in the same critical section,
and prevents race conditions similar to the case fixed by Bug 14262 :
- thread 1 executes DROP TRIGGER IF EXISTS, access() returns a failure
- thread 2 executes CREATE TRIGGER
- thread 2 logs CREATE TRIGGER
- thread 1 logs DROP TRIGGER IF EXISTS
The patch itself is based on code contributed by the MySQL community,
under the terms of the Contributor License Agreement (See Bug 18161).
warnings in sql_trigger.cc and sql_view.cc".
According to the current version of C++ standard offsetof() macro
can't be used for non-POD types. So warnings were emitted when we
tried to use this macro for TABLE_LIST and Table_triggers_list
classes. Note that despite of these warnings it was probably safe
thing to do.
This fix tries to circumvent this limitation by implementing
custom version of offsetof() macro to be used with these
classes. This hack should go away once we will refactor
File_parser class.
Alternative approaches such as disabling this warning for
sql_trigger.cc/sql_view.cc or for the whole server were
considered less explicit. Also I was unable to find a way
to disable particular warning for particular _part_ of
file in GCC.
(race cond)
It was possible for one thread to interrupt a Data Definition Language
statement and thereby get messages to the binlog out of order. Consider:
Connection 1: Drop Foo x
Connection 2: Create or replace Foo x
Connection 2: Log "Create or replace Foo x"
Connection 1: Log "Drop Foo x"
Local end would have Foo x, but the replicated slaves would not.
The fix for this is to wrap all DDL and logging of a kind in the same mutex.
Since we already use mutexes for the various parts of altering the server,
this only entails moving the logging events down close to the action, inside
the mutex protection.
this key does not stop" (version for 5.0 only).
UPDATE statement which WHERE clause used key and which invoked trigger
that modified field in this key worked indefinetely.
This problem occured because in cases when UPDATE statement was
executed in update-on-the-fly mode (in which row is updated right
during evaluation of select for WHERE clause) the new version of
the row became visible to select representing WHERE clause and was
updated again and again.
We already solve this problem for UPDATE statements which does not
invoke triggers by detecting the fact that we are going to update
field in key used for scanning and performing update in two steps,
during the first step we gather information about the rows to be
updated and then doing actual updates. We also do this for
MULTI-UPDATE and in its case we even detect situation when such
fields are updated in triggers (actually we simply assume that
we always update fields used in key if we have before update
trigger).
The fix simply extends this check which is done in check_if_key_used()/
QUICK_SELECT_I::check_if_keys_used() routine/method in such way that
it also detects cases when field used in key is updated in trigger.
As nice side-effect we have more precise and thus more optimal
perfomance-wise check for the MULTI-UPDATE.
Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were
renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to
better reflect that boolean predicate.
Note that this check is implemented in much more elegant way in 5.1
There is an existing macros for initializing LEX_STRINGs
with constant strings -> C_STRING_WITH_LEN. Change existing code to use it.
(char *) STRING_WITH_LEN -> C_STRING_WITH_LEN
Continued implementation of WL#1324 (table name to filename encoding)
The intermediate (not temporary) files of the new table
during ALTER TABLE was visible for SHOW TABLES. These
intermediate files are copies of the original table with
the changes done by ALTER TABLE. After all the data is
copied over from the original table, these files are renamed
to the original tables file names. So they are not temporary
files. They persist after ALTER TABLE, but just with another
name.
In 5.0 the intermediate files are invisible for SHOW TABLES
because all file names beginning with "#sql" were suppressed.
This failed since 5.1.6 because even temporary table names were
converted when making file names from them. The prefix became
converted to "@0023sql". Converting the prefix during SHOW TABLES
would suppress the listing of user tables that start with "#sql".
The solution of the problem is to continue the implementation of
the table name to file name conversion feature. One requirement
is to suppress the conversion for temporary table names.
This change is straightforward for real temporary tables as there
is a function that creates temporary file names.
But the generated path names are located in TMPDIR and have no
relation to the internal table name. This cannot be used for
ALTER TABLE. Its intermediate files need to be in the same
directory as the old table files. And it is necessary to be
able to deduce the same path from the same table name repeatedly.
Consequently the intermediate table files must be handled like normal
tables. Their internal names shall start with tmp_file_prefix
(#sql) and they shall not be converted like normal table names.
I added a flags parameter to all relevant functions that are
called from ALTER TABLE. It is used to suppress the conversion
for the intermediate table files.
The outcome is that the suppression of #sql in SHOW TABLES
works again. It does not suppress user tables as these are
converted to @0023sql on file level.
This patch does also fix ALTER TABLE ... RENAME, which could not
rename a table with non-ASCII characters in its name.
It does also fix the problem that a user could create a table like
`#sql-xxxx-yyyy`, where xxxx is mysqld's pid and yyyy is the thread
ID of some other thread, which prevented this thread from running
ALTER TABLE.
Some of the above problems are mentioned in Bug 1405, which can
be closed with this patch.
This patch does also contain some minor fixes for other forgotten
conversions. Still known problems are reported as bugs 21370,
21373, and 21387.
can be not replicable.
Now CREATE statements for writing in the binlog are created as follows:
- the beginning of the statement is re-created;
- the rest of the statement is copied from the original query.
The problem appears when there is a version-specific comment (produced by
mysqldump), started in the re-created part of the statement and closed in the
copied part -- there is closing comment-parenthesis, but there is no opening
one.
The proper fix could be to re-create original statement, but we can not
implement it in 5.0. So, for 5.0 the fix is just to cut closing
comment-parenthesis. This technique is also used for SHOW CREATE PROCEDURE
statement (so we are able to reuse existing code).
context.
Routine arguments were evaluated in the security context of the routine
itself, not in the caller's context.
The bug is fixed the following way:
- Item_func_sp::find_and_check_access() has been split into two
functions: Item_func_sp::find_and_check_access() itself only
finds the function and check that the caller have EXECUTE privilege
on it. New function set_routine_security_ctx() changes security
context for SUID routines and checks that definer have EXECUTE
privilege too.
- new function sp_head::execute_trigger() is called from
Table_triggers_list::process_triggers() instead of
sp_head::execute_function(), and is effectively just as the
sp_head::execute_function() is, with all non-trigger related code
removed, and added trigger-specific security context switch.
- call to Item_func_sp::find_and_check_access() stays outside
of sp_head::execute_function(), and there is a code in
sql_parse.cc before the call to sp_head::execute_procedure() that
checks that the caller have EXECUTE privilege, but both
sp_head::execute_function() and sp_head::execute_procedure() call
set_routine_security_ctx() after evaluating their parameters,
and restore the context after the body is executed.
