procedure
For some functions returning strings (like "replace" and "ifnull" - where
val_str() is returning a pointer into one of the parameters) - we ended
up with a dangling pointer after the new operator destroyed the reuse item
in the eval function.
A working, if not very elegant, solution is to simply copy the string in
such cases.
can't be executed on slave". It will be possible to solve this problem
in more correct way when we will implement WL#2897 "Complete definer support
in the stored routines".
Ensure that ccache is also used for C programs
mysql: Ensure that 'delimiter' works the same way in batch mode as in normal mode
mysqldump: Change to use ;; (instead of //) as a stored procedure/trigger delimiter
Fixed test cases by adding missing DROP's and rename views to be of type 'v#'
Removed MY_UNIX_PATH from fn_format()
Removed current_db_used from TABLE_LIST
Removed usage of 'current_thd' in Item_splocal
Removed some compiler warnings
A bit faster longlong2str code
displays error
When returning to the old database (which may be ""), don't do
access check - mysql_change_db() would then generate the error
"No database selected".
Note: No test case added; it seems a db is always selected when running
tests.
Search the chain of sp_rcontexts recursively for handlers. If one is found,
it will be detected in the sp_head::execute() method at the corresponding
level.
Replaced the dumb in-handler/not-in-handler check with a proper recursion
check of handlers being executed.
(Re-commit in a different tree, to make push possible.)
cursor is interpreted latin1 character and Bug#9819 "Cursors: Mysql Server
Crash while fetching from table with 5 million records."
A fix for a possible memory leak when fetching into an SP cursor
in a long loop.
The patch uses a common implementation of cursors in the binary protocol and
in stored procedures and implements materialized cursors.
For implementation details, see comments in sql_cursor.cc
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.
thd->user_var_events_alloc (and so get binlog events to be allocated on its pool),
clean the binlog events after the execution of this SP statement is finished.
* Allocate thd->user_var_events elements on appropriate mem_root
* If several SP statements are binlogged as a single statement, collect all user var
accesses they make (grep for StoredRoutinesBinlogging for details)
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.
NOT FOUND ...' in conditional handled incorrectly".
Whenever we remove an instruction during optimization, we need to
adjust instruction numbers (ip - instruction pointer) stored in all
instructions. In addition to that, sp_instr_hpush_jump, which
corresponds to DECLARE CONTINUE HANDLER needs adjustment for m_handler,
which holds the number of instruction with the continue handler.
In the bug report, a wrong ip stored in m_handler was pointing at
FETCH, which resulted in an error message and abnormal SP termination.
The fix is to just remove m_handler member from sp_instr_hpush_jump,
as it's always points to the instruction next to the DECLARE
statement itself (m_ip+1).
and Bug#12297 SP crashes the server if data inserted inside a lon loop
Third commit attempt. With fixes to the issues, showed up after full rebuild and
tests on other hosts.
This allows us to use statement replication with functions and triggers
The following things are fixed with this patch:
- NOW() and automatic timestamps takes the value from the main event for functions and triggers (which allows these to replicate with statement level logging)
- No side effects for triggers or functions with auto-increment values(), last_insert_id(), rand() or found_rows()
- Triggers can't return result sets
Fixes bugs:
#12480: NOW() is not constant in a trigger
#12481: Using NOW() in a stored function breaks statement based replication
#12482: Triggers has side effects with auto_increment values
#11587: trigger causes lost connection error
