mariadb

Commit Graph

Author	SHA1	Message	Date
unknown	57dc12563f	Trivial cleanups and whitespace change in Event Scheduler code. A larger patch is to come, this is to exclude rudimentary changes from it. sql/event_data_objects.cc: Whitespace change. sql/event_data_objects.h: Remove debug allocators - we have safemalloc. sql/event_db_repository.cc: Whitespace change. sql/event_db_repository.h: Whitespace change. sql/event_queue.cc: Remove an unused structure. Whitespace change. sql/event_queue.h: Whitespace. sql/event_scheduler.cc: Whitespace change. sql/event_scheduler.h: Add comments. Whitespace change. sql/events.cc: Whitespace change. sql/events.h: Trivial cleanups.	19 years ago
unknown	858ff63811	Fix warnings on Windows. sql/event_data_objects.cc: Fix Windows 64 bit build warnings. No better fix exists at the moment.	19 years ago
unknown	c71bff6d1c	sql_insert.cc: After merge fix. sql/sql_insert.cc: After merge fix.	19 years ago
unknown	3798a7d500	sql_insert.cc: Removed wrong fix for the bug#27006. The bug was added by the fix for the bug#19978 and fixed by Monty on 2007/02/21. trigger.test, trigger.result: Corrected test case for the bug#27006. sql/sql_insert.cc: Removed wrong fix for the bug#27006. The bug was added by the fix for the bug#19978 and fixed by Monty on 2007/02/21. mysql-test/t/trigger.test: Corrected test case for the bug#27006. mysql-test/r/trigger.result: Corrected test case for the bug#27006.	19 years ago
unknown	7d383909db	wl#3700 - post-review fixes: s/ulonglong/key_part_map/, comments include/heap.h: wl#3700 - post-review fixes: s/ulonglong/key_part_map/ include/my_base.h: wl#3700 - post-review fixes: s/ulonglong/key_part_map/ include/myisam.h: wl#3700 - post-review fixes: s/ulonglong/key_part_map/ include/myisammrg.h: wl#3700 - post-review fixes: s/ulonglong/key_part_map/ sql/event_db_repository.cc: wl#3700 - post-review fixes: s/ulonglong/key_part_map/ sql/ha_partition.cc: wl#3700 - post-review fixes: s/ulonglong/key_part_map/ sql/ha_partition.h: wl#3700 - post-review fixes: s/ulonglong/key_part_map/ sql/sql_select.h: wl#3700 - post-review fixes: remove tab_to_keypart_map()	19 years ago
unknown	84d24679b9	sql_insert.cc: Post-merge fix. sql/sql_insert.cc: Post-merge fix.	19 years ago
unknown	68f09e7792	merging	19 years ago
unknown	998260ae5a	Fix compilation on Windows broken with the push of bug#16420. Fix three compilation warnings. sql/event_data_objects.cc: Fix compilation warnings. sql/event_queue.cc: Fix compilation warning: reimplement event_queue_element_compare_q() properly. Use set_timespec() to initialize struct timespec.	19 years ago
unknown	086fba7627	BUG#16420: Events: timestamps become UTC BUG#26429: SHOW CREATE EVENT is incorrect for an event that STARTS NOW() BUG#26431: Impossible to re-create an event from backup if its STARTS clause is in the past WL#3698: Events: execution in local time zone The problem was that local times specified by the user in AT, STARTS and ENDS of CREATE EVENT/ALTER EVENT statement were converted to UTC, and the original time zone was forgotten. This way, event scheduler couldn't honor Daylight Saving Time shifts, and times shown to the user were also in UTC. Additionally, CREATE EVENT didn't allow times in the past, thus preventing straightforward event restoration from old backups. This patch reworks event scheduler time computations, performing them in the time zone associated with the event. Also it allows times to be in the past. The patch adds time_zone column to mysql.event table. NOTE: The patch is almost final, but the bug#9953 should be pushed first. client/mysqldump.c: Before every CREATE EVENT, output its time zone. mysql-test/include/wait_condition.inc: Add optional $wait_timeout parameter. mysql-test/lib/init_db.sql: Add time_zone column. mysql-test/r/events.result: Update result. mysql-test/r/events_bugs.result: Update result. mysql-test/r/events_grant.result: Update result. mysql-test/r/events_restart_phase1.result: Update result. mysql-test/r/events_scheduling.result: Update result. mysql-test/r/mysqldump.result: Update result. mysql-test/r/ps.result: Update result. mysql-test/r/system_mysql_db.result: Update result. mysql-test/t/events.test: Remove STARTS from the result, as it depends on current time. mysql-test/t/events_bugs.test: Time in the past is no longer an error. mysql-test/t/events_restart_phase1.test: Fill new column 'time_zone' in mysql.event. mysql-test/t/events_scheduling.test: Cleanup: disable event scheduler. scripts/mysql_create_system_tables.sh: Add new column 'time_zone' to mysql.event. scripts/mysql_fix_privilege_tables.sql: Add new column 'time_zone' to mysql.event. sql/event_data_objects.cc: The essence of the change is the following: - for internal times use my_time_t instead of TIME. Assignment and comparison is done now on plain numbers. - in init_execute_at(), init_starts(), init_ends() convert given time to number of seconds since Epoch (aka Unix time, in UTC). - handle time_zone field loading and storing. - in get_next_time(), Unix time is converted back to event time zone, interval is added, and the result is converted to UTC again. - fix Event_timed::get_create_event() to report STARTS and ENDS. - before executing the event body we set thread time zone to the event time zone. sql/event_data_objects.h: Add time_zone member to Event_basic class. Store internal times in my_time_t (number of seconds since Epoch), rather than in broken down TIME structure. sql/event_db_repository.cc: Add time_zone column handling. Give a warning and do not create an event if its execution time is in the past, and ON COMPLETION NOT PRESERVE is set, because such an event should be dropped by that time. Also, do not allow ALTER EVENT to set execution time in the past when ON COMPLETION NOT PRESERVE is set. sql/event_db_repository.h: Add enum member for new time zone column. sql/event_queue.cc: Replace handling of broken down times with simple handling of my_time_t. sql/event_queue.h: Store internal times in my_time_t (number of seconds since Epoch), rather than in broken down TIME structure. sql/event_scheduler.cc: Add TODO comment. sql/events.cc: Send time_zone column for SHOW CREATE EVENT. sql/share/errmsg.txt: Update error message, and add two more errors. sql/sql_show.cc: Add TIME_ZONE column to the output of SHOW EVENTS. mysql-test/r/events_time_zone.result: BitKeeper file /home/tomash/src/mysql_ab/mysql-5.1-wl3698/mysql-test/r/events_time_zone.result mysql-test/t/events_time_zone.test: BitKeeper file /home/tomash/src/mysql_ab/mysql-5.1-wl3698/mysql-test/t/events_time_zone.test	19 years ago
unknown	6d93f15039	Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed. This bug was caused by fix for bug#19978. It causes AFTER UPDATE triggers not firing if a row wasn't actually changed by the update part of the INSERT .. ON DUPLICATE KEY UPDATE. Now triggers are always fired if a row is touched by the INSERT ... ON DUPLICATE KEY UPDATE. sql/sql_insert.cc: Bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed. Now triggers are always fired if a row is touched by the INSERT ... ON DUPLICATE KEY UPDATE. mysql-test/r/trigger.result: Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed. mysql-test/t/trigger.test: Added a test case for the bug#27006: AFTER UPDATE triggers not fired with INSERT ... ON DUPLICATE KEY UPDATE if the row wasn't actually changed.	19 years ago
unknown	2b2fb67460	Bug#26807 "set global event_scheduler=1" and --skip-grant-tables crashes server - Crash occured because Event engine is only initialized if ACLs are used but not properly marked as disabled. - The patch is to mark the Event engine as DISABLED if no ACLs are used to avoid access of uninitialized variables. mysql-test/r/skip_grants.result: Added test case mysql-test/t/skip_grants.test: Added test case	19 years ago
unknown	2e8e78a42c	Bug #26261 : INSERT uses query_id to verify what fields are mentioned in the fields list of the INSERT command. However the check for that is made after the ON DUPLICATE KEY is processed. This causes all the fields mentioned in ON DUPLICATE KEY to be considered as mentioned in the fields list of INSERT. Moved the check up, right after processing the fields list. mysql-test/r/insert_update.result: Bug #26261: test case mysql-test/t/insert_update.test: Bug #26261: test case sql/mysql_priv.h: Bug #26261: moved the check inside mysql_prepare_insert sql/sql_insert.cc: Bug #26261: move the check inside mysql_prepare_insert before setting up the ON DUPLICATE KEY part sql/sql_prepare.cc: Bug #26261: moved the check inside mysql_prepare_insert	19 years ago
unknown	a51b768600	Bug#26285 selecting information_schema crahes server The crash happens when 'skip-grant-tables' is enabled. We skip the filling of I_S privilege tables if acl_cache is not initialized. mysql-test/r/skip_grants.result: test result mysql-test/t/skip_grants.test: test case sql/sql_acl.cc: skip filling of I_S privilege tables if acl_cache is not initialized	19 years ago
unknown	542f18a31a	Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. The LAST_INSERT_ID() is reset to 0 if no rows were inserted or changed. This is the case when an INSERT ... ON DUPLICATE KEY UPDATE updates a row with the same values as the row contains. Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows successfully inserted or touched. The new 'touched' field is added to the COPY_INFO structure. It holds the number of rows that were touched no matter whether they were actually changed or not. sql/sql_class.h: Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. The new 'touched' field is added to the COPY_INFO structure. It holds the number of rows that were touched no matter whether they were actually changed or not. mysql-test/r/insert_update.result: Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. mysql-test/t/insert_update.test: Added a test case for the bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. sql/sql_insert.cc: Bug#27033: 0 as LAST_INSERT_ID() after INSERT .. ON DUPLICATE if rows were touched but not actually changed. Now the LAST_INSERT_ID() values is reset to 0 only if there were no rows successfully inserted or touched.	19 years ago
unknown	cdd2a2e40d	Fix for bug #25966 "2MB per second endless memory consumption after LOCK TABLE ... WRITE". Memory and CPU hogging occured when connection which had to wait for table lock was serviced by thread which previously serviced connection that was killed (note that connections can reuse threads if thread cache is enabled). One possible scenario which exposed this problem was when thread which provided binlog dump to replication slave was implicitly/automatically killed when the same slave reconnected and started pulling data through different thread/connection. The problem also occured when one killed particular query in connection (using KILL QUERY) and later this connection had to wait for some table lock. This problem was caused by the fact that thread-specific mysys_var::abort variable, which indicates that waiting operations on mysys layer should be aborted (this includes waiting for table locks), was set by kill operation but was never reset back. So this value was "inherited" by the following statements or even other connections (which reused the same physical thread). Such discrepancy between this variable and THD::killed flag broke logic on SQL-layer and caused CPU and memory hogging. This patch tries to fix this problem by properly resetting this member. There is no test-case associated with this patch since it is hard to test for memory/CPU hogging conditions in our test-suite. sql/mysqld.cc: We should not forget to reset THD::mysys_var::abort after kill operation if we are going to use thread to which this operation was applied for handling of other connections. sql/sp_head.cc: We should not forget to reset THD::mysys_var::abort after kill operation if we are going to use thread to which this operation was applied for handling of further statements. sql/sql_parse.cc: We should not forget to reset THD::mysys_var::abort after kill operation if we are going to use thread to which this operation was applied for handling of further statements.	19 years ago
unknown	db1d2f64d1	Fix for bug #25966 "2MB per second endless memory consumption after LOCK TABLE ... WRITE". CPU hogging occured when connection which had to wait for table lock was serviced by thread which previously serviced connection that was killed (note that connections can reuse threads if thread cache is enabled). One possible scenario which exposed this problem was when thread which provided binlog dump to replication slave was implicitly/automatically killed when the same slave reconnected and started pulling data through different thread/connection. In 5.* versions memory hogging was added to CPU hogging. Moreover in those versions the problem also occured when one killed particular query in connection (using KILL QUERY) and later this connection had to wait for some table lock. This problem was caused by the fact that thread-specific mysys_var::abort variable, which indicates that waiting operations on mysys layer should be aborted (this includes waiting for table locks), was set by kill operation but was never reset back. So this value was "inherited" by the following statements or even other connections (which reused the same physical thread). Such discrepancy between this variable and THD::killed flag broke logic on SQL-layer and caused CPU and memory hogging. This patch tries to fix this problem by properly resetting this member. There is no test-case associated with this patch since it is hard to test for memory/CPU hogging conditions in our test-suite. sql/mysqld.cc: We should not forget to reset THD::mysys_var::abort after kill operation if we are going to use thread to which this operation was applied for handling of other connections.	19 years ago
unknown	2fad8ac2fc	Manual merge from 5.0-runtime to 5.1-runtime	19 years ago
unknown	79344c7b67	Bug#26503 (Illegal SQL exception handler code causes the server to crash) Before this fix, the parser would accept illegal code in SQL exceptions handlers, that later causes the runtime to crash when executing the code, due to memory violations in the exception handler stack. The root cause of the problem is instructions within an exception handler that jumps to code located outside of the handler. This is illegal according to the SQL 2003 standard, since labels located outside the handler are not supposed to be visible (they are "out of scope"), so any instruction that jumps to these labels, like ITERATE or LEAVE, should not parse. The section of the standard that is relevant for this is : SQL:2003 SQL/PSM (ISO/IEC 9075-4:2003) section 13.1 <compound statement>, syntax rule 4 <quote> The scope of the <beginning label> is CS excluding every <SQL schema statement> contained in CS and excluding every <local handler declaration list> contained in CS. <beginning label> shall not be equivalent to any other <beginning label>s within that scope. </quote> With this fix, the C++ class sp_pcontext, which represent the "parsing context" tree (a.k.a symbol table) of a stored procedure, has been changed as follows: - constructors have been cleaned up, so that only building a root node for the tree is public; building nodes inside a tree is not public. - a new member, m_label_scope, indicates if a given syntactic context belongs to a DECLARE HANDLER block, - label resolution, in the method find_label(), has been changed to implement the restriction of scope regarding labels used in a compound statement. The actions in the parser, when parsing the body of a SQL exception handler, have been changed as follows: - the implementation of an exception handler (DECLARE HANDLER) now creates explicitly a new sp_pcontext, to isolate the code inside the handler from the containing compound statement context. - registering exception handlers as a result occurs in the parent context, see the rule sp_hcond_element - the code in sp_hcond_list has been cleaned up, to avoid code duplication In addition, the flags IN_SIMPLE_CASE and IN_HANDLER, declared in sp_head.h have been removed, since they are unused and broken by design (as seen with Bug 19194 (Right recursion in parser for CASE causes excessive stack usage, limitation), representing a stack in a single flag is not possible. Tests in sp-error have been added to show that illegal constructs are now rejected. Tests in sp have been added for code coverage, to show that ITERATE or LEAVE statements are legal when jumping to a label in scope, inside the body of an exception handler. mysql-test/r/sp-error.result: SQL Exception handlers define a parsing context for label resolution. mysql-test/r/sp.result: SQL Exception handlers define a parsing context for label resolution. mysql-test/t/sp-error.test: SQL Exception handlers define a parsing context for label resolution. mysql-test/t/sp.test: SQL Exception handlers define a parsing context for label resolution. sql/sp_head.cc: Minor cleanup sql/sp_head.h: Minor cleanup sql/sp_pcontext.cc: SQL Exception handlers define a parsing context for label resolution. sql/sp_pcontext.h: SQL Exception handlers define a parsing context for label resolution. sql/sql_yacc.yy: SQL Exception handlers define a parsing context for label resolution.	19 years ago
unknown	7e237e4f35	Bug #26794 : fixed valgrind warning	19 years ago
unknown	ff810fb952	Bug #26794 : fixed valgrind warning	19 years ago
unknown	f0c5044096	WL#3527 : inspected a 5.1 covarage report sql/item.cc: WL#3527 : inspected a covarage report	19 years ago
unknown	7a3148a7aa	Bug #24778 : Innodb: No result when using ORDER BY This bug was intruduced by the fix for bug#17212 (in 4.1). It is not ok to call test_if_skip_sort_order since this function will alter the execution plan. By contract it is not ok to call test_if_skip_sort_order in this context. This bug appears only in the case when the optimizer has chosen an index for accessing a particular table but finds a covering index that enables it to skip ORDER BY. This happens in test_if_skip_sort_order. mysql-test/r/key.result: Bug#24778 test case. The bug causes the result to be the empty set. mysql-test/t/key.test: Bug#24778 The minimal test case that reveals the bug. The reason for such a complicated schema is that we have to convince the optimizer to pick one index, then discard it in order to be able to skip ORDER BY. sql/sql_select.cc: bug#24778 Removed the call to test_if_skip_sort_order that constituted the bug.	19 years ago
unknown	6e10a2048d	Bug #26794 : 5.1 part It was syntactically correct to define spatial keys over parts of columns (e.g. ALTER TABLE t1 ADD x GEOMETRY NOT NULL, ADD SPATIAL KEY (x(32))). This may lead to undefined results and/or interpretation. Fixed by not allowing partial column specification in a SPATIAL index definition. mysql-test/r/alter_table.result: Bug #26794: 5.1 part test case mysql-test/r/gis-rtree.result: Bug #26794: 5.1 part updated the tests to the new syntax mysql-test/t/alter_table.test: Bug #26794: 5.1 part test case mysql-test/t/gis-rtree.test: Bug #26794: 5.1 part updated the tests to the new syntax sql/sql_table.cc: Bug #26794: 5.1 part Disable defining SPATIAL KEYS with sub-key parts	19 years ago
unknown	a22f257e04	Bug #26794 : Different set of conditions is used to verify the validity of index definitions over a GEOMETRY column in ALTER TABLE and CREATE TABLE. The difference was on how sub-keys notion validity is checked. Fixed by extending the CREATE TABLE condition to support the cases allowed in ALTER TABLE. Made the SHOW CREATE TABLE not to display spatial indexes using the sub-key notion. mysql-test/r/alter_table.result: Bug #26794: test case mysql-test/r/gis-rtree.result: Bug #26794: fixed SHOW CREATE TABLE output. mysql-test/t/alter_table.test: Bug #26794: test case sql/field.cc: Bug #26794: Allow sub-keys for GEOMETRY sql/sql_show.cc: Bug #26794: Don't show sub-key notion in SHOW CREATE TABLE for SPATIAL indexes. sql/sql_table.cc: Bug #26794: Allow sub-keys for GEOMETRY	19 years ago
unknown	fa57a563ce	Fix the bug introduced with the push of the fix for bug#18326: Do not lock table for writing during prepare of statement. When single call open_normal_and_derived_tables() was used, we never set table_count to the right value. This patch reverts the part of the old code that does open_tables() (and sets table_count), then checks if table_list->multitable_view is set (and returns if so, using table_count value), and only then it does mysql_handle_derived().	19 years ago
unknown	969b71653d	BUG#26881 - Large MERGE tables report incorrect specification when no differences in tables Certain merge tables were wrongly reported as having incorrect definition: - Some fields that are 1 byte long (e.g. TINYINT, CHAR(1)), might be internally casted (in certain cases) to a different type on a storage engine layer. (affects 4.1 and up) - If tables in a merge (and a MERGE table itself) had short VARCHAR column (less than 4 bytes) and at least one (but not all) tables were ALTER'ed (even to an identical table: ALTER TABLE xxx ENGINE=yyy), table definitions went ouf of sync. (affects 4.1 only) This is fixed by relaxing a check for underlying conformance and setting field type to FIELD_TYPE_STRING in case varchar is shorter than 4 when a table is created. myisam/mi_create.c: Added a comment. mysql-test/r/merge.result: A test case for bug#26881. mysql-test/t/merge.test: A test case for bug#26881. sql/ha_myisam.cc: Relaxed some checks performed by check_definition(): As comparing of fulltext keys (and key segments) is not yet implemented, only return an error in case one of keys is fulltext and other is not. Otherwise, if both keys are fulltext, accept them as is. As comparing of spatial keys (and key segments) is not yet implemented, only return an error in case one of keys is spatial and other is not. Otherwise, if both keys are spatial, accept them as is. A workaround to handle situation when field is casted from FIELD_SKIP_ZERO to FIELD_NORMAL. This could happen only in case field length is 1 and row format is fixed. sql/sql_parse.cc: When a table that has varchar field shorter than 4 is created, field type is set to FIELD_TYPE_VAR_STRING. Later, when a table is modified using alter table, field type is changed to FIELD_TYPE_STRING (see Field_string::type). That means HA_OPTION_PACK_RECORD flag might be lost and thus null_bit might be shifted by alter table, in other words alter table doesn't create 100% equal table definition. This is usually not a problem, since when a table is created/altered, definition on a storage engine layer is based on one that is passed from sql layer. But it is a problem for merge engine - null_bit is shifted when a table (merge or underlying) is altered. Set field type to FIELD_TYPE_STRING in case FIELD_TYPE_VAR_STRING is shorter than 4 when a table is created as it is done in Field::type.	19 years ago
unknown	bd6aecf3f3	Bug #26794 : Different set of conditions is used to verify the validity of index definitions over a GEOMETRY column in ALTER TABLE and CREATE TABLE. The difference was on how sub-keys notion validity is checked. Fixed by extending the CREATE TABLE condition to support the cases allowed in ALTER TABLE. Made the SHOW CREATE TABLE not to display spatial indexes using the sub-key notion. mysql-test/r/alter_table.result: Bug #26794: test case mysql-test/r/gis-rtree.result: Bug #26794: fixed SHOW CREATE TABLE output. mysql-test/t/alter_table.test: Bug #26794: test case sql/field.cc: Bug #26794: Allow sub-keys for GEOMETRY sql/sql_show.cc: Bug #26794: Don't show sub-key notion in SHOW CREATE TABLE for SPATIAL indexes. sql/sql_table.cc: Bug #26794: Allow sub-keys for GEOMETRY	19 years ago
unknown	4ce3624ec4	group_by.result: WL3527: disable wrong optimization. sql_select.cc: WL#3527: disable wrong optimization. sql/sql_select.cc: WL#3527: disable wrong optimization. mysql-test/r/group_by.result: WL3527: disable wrong optimization.	19 years ago
unknown	91abf15ed2	Fixed bug #26738 : incomplete string values in a result set column when the column is to be read from a derived table column which was specified as a concatenation of string literals. The bug happened because the Item_string::append did not adjust the value of Item_string::max_length. As a result of it the temporary table column defined to store the concatenation of literals was not wide enough to hold the whole value. mysql-test/r/subselect.result: Added a test case for bug #26738. mysql-test/t/subselect.test: Added a test case for bug #26738.	19 years ago
unknown	13c05162f3	Fixed bug #26963 : invalid optimization of the pushdown conditions after single-row table substitution could lead to a wrong result set. The bug happened because the function Item_field::replace_equal_field erroniously assumed that any field included in a multiple equality with a constant has been already substituted for this constant. This not true for fields becoming constant after row substitutions for constant tables. mysql-test/r/select.result: Added a test case for bug #26963. mysql-test/t/select.test: Added a test case for bug #26963. sql/item.cc: Fixed bug #26963: invalid optimization of the pushdown conditions after single-row table substitution could lead to a wrong result set. The bug happened because the function Item_field::replace_equal_field erroneously assumed that any field included in a multiple equality with a constant has been already substituted for this constant. This not true for fields becoming constant after row substitutions for constant tables.	19 years ago
unknown	0f79336948	WL3527: post-merge updates sql_yacc.yy: WL3527: updated the diff to use correct parser words table.cc: WL3527: exteneded the fix for bug #20604 to fit the new variables sql_select.cc: WL3527: renamed used_keys to covering_keys sql/sql_select.cc: renamed used_keys to covering_keys sql/sql_yacc.yy: WL3527: updated the diff to use correct parser words sql/table.cc: WL3527: exteneded the fix for bug #20604 to fit the new variables	19 years ago
unknown	816ea8a379	Bug#15757: Wrong SUBSTRING() result when a tmp table was employed. When the SUBSTRING() function was used over a LONGTEXT field the max_length of the SUBSTRING() result was wrongly calculated and set to 0. As the max_length parameter is used while tmp field creation it limits the length of the result field and leads to printing an empty string instead of the correct result. Now the Item_func_substr::fix_length_and_dec() function correctly calculates the max_length parameter. mysql-test/t/func_str.test: Added a test case for the bug#15757: Wrong SUBSTRING() result when a tmp table was employed. mysql-test/r/func_str.result: Added a test case for the bug#15757: Wrong SUBSTRING() result when a tmp table was employed. sql/item_strfunc.cc: Bug#15757: Wrong SUBSTRING() result when a tmp table was employed. Now the Item_func_substr::fix_length_and_dec() function correctly calculates the max_length parameter.	19 years ago
unknown	67733ea5f8	bug #26833 (Compile error with embedded lib) org_tables declaration was mistakenly #ifdef-ed with the EMBEDDED_LIBRARY instead of ACCESS_CHECKS sql/sql_parse.cc: default condition fixed	19 years ago
unknown	4d6ad7ac60	Fixed bug #26830 : a crash for the query with a subselect containing ROLLUP. Crash happened because the function get_best_group_min_max detected joins with ROLLUP incorrectly. mysql-test/r/olap.result: Added a test case for bug #26830. mysql-test/t/olap.test: Added a test case for bug #26830.	19 years ago
unknown	944030aef7	Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Additional fix for bug#22331. Now Item_field prints its value in the case of the const field. mysql-test/r/varbinary.result: Corrected test case after fix for bug#22331. mysql-test/r/union.result: Corrected test case after fix for bug#22331. mysql-test/r/subselect.result: Corrected test case after fix for bug#22331. mysql-test/r/func_test.result: Corrected test case after fix for bug#22331. mysql-test/r/having.result: Corrected test case after fix for bug#22331. mysql-test/r/func_regexp.result: Corrected test case after fix for bug#22331. mysql-test/r/func_str.result: Corrected test case after fix for bug#22331. mysql-test/r/func_default.result: Corrected test case after fix for bug#22331. mysql-test/r/explain.result: Corrected test case after fix for bug#22331. sql/sql_union.cc: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Cleanup of the SELECT_LEX::order_list list. sql/item.h: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Added the print() member function to the Item_field class. sql/item.cc: Bug#22331: Wrong WHERE in EXPLAIN EXTENDED when all expressions were optimized away. Added the print() member function to the Item_field class.	19 years ago
unknown	dca006dfd2	Fix for BUG#735 "Prepared Statements: there is no support for Query Cache". WL#1569 "Prepared Statements: implement support of Query Cache". Prepared SELECTs did not look up in the query cache, and their results were not stored in the query cache. This made them slower than non-prepared SELECTs in some cases. The fix is to re-use the expanded query (the prepared query where "?" placeholders are replaced by their values, at execution time) for searching/storing in the query cache. It works fine for statements prepared via mysql_stmt_prepare(), which are the most commonly used and were the scope of this bugfix and WL. It works less fine for statements prepared via the SQL command PREPARE...FROM, which are still not using the query cache if they have at least one parameter (because then the expanded query contains names of user variables, and user variables don't work with the query cache, even in non-prepared queries). Note that results from prepared SELECTs, which are in the binary protocol, and results from normal SELECTs, which are in the text protocol, ignore each other in the query cache, because a result in the binary protocol should never be served to a SELECT expecting the text protocol and vice-versa. Note, after this patch, bug 25843 starts applying to query cache ("changing default database between PREPARE and EXECUTE of statement breaks binlog"), we need to fix it. mysql-test/include/have_query_cache.inc: Now prepared statements work with the query cache, so don't disable prep stmts by default when doing a query cache test. All tests which include this file will now be really tested against prepared statements (in particular, query_cache.test). mysql-test/r/query_cache.result: result update mysql-test/t/grant_cache.test: Cannot enable this test in ps-protocol, because in normal protocol, a SELECT failing due to insufficient privileges increments Qcache_not_cached, while in ps-protocol, no. In detail: in normal protocol, the "access denied" errors on SELECT are issued at (stack trace): mysql_parse/mysql_execute_command/execute_sqlcom_select/handle_select/ mysql_select/JOIN::prepare/setup_wild/insert_fields/ check_grant_all_columns/my_error/my_message_sql, which then calls push_warning/query_cache_abort: at this moment, query_cache_store_query() has been called, so query exists in cache, so thd->net.query_cache_query!=NULL, so query_cache_abort() removes the query from cache, which causes a query_cache.refused++ (thus, a Qcache_not_cached++). While in ps-protocol, the error is issued at prepare time; for this mysql_test_select() is called, not execute_sqlcom_select() (and that also leads to JOIN::prepare/etc). Thus, as query_cache_store_query() has not been called, thd->net.query_cache_query==NULL, so query_cache_abort() does nothing: Qcache_not_cached is not incremented. As this test prints Qcache_not_cached after SELECT failures, we cannot enable this test in ps-protocol. mysql-test/t/ndb_cache_multi2.test: The principle of this test is: two mysqlds connected to one cluster, both using their query cache. Queries are cached in server1 ("select a!=3 from t1", "select * from t1"), table t1 is modified in server2, we want to see that this invalidates the query cache of server1. Invalidation with NDB works like this: when a query is found in the query cache, NDB is asked if the tables have changed. In this test, ha_ndbcluster calls NDB every millisecond to collect change information about tables. Due to this millisecond delay, there is need for a loop ("while...") in this test, which waits until a query1 ("select a!=3 from t1") is invalidated (which is equivalent to it returning up-to-date results), and then expects query2 ("select * from t1") to have been invalidated (see up-to-date results). But when enabling --ps-protocol in this test, the logic breaks, because query1 is still done via mysql_real_query() (see mysqltest.c: eval_expr() always uses mysql_real_query()). So, query1 returning up-to-date results is not a sign of it being invalidated in the cache, because it was NOT in the cache ("select a!=3 from t1" on line 39 was done with prep stmts, while `select a!=3 from t1` is not, thus the second does not see the first in the cache). Thus, we may run query2 when cache still has not been invalidated. The solution is to make the initial "select a!=3 from t1" run as a normal query, this repairs the broken logic. But note, "select * from t1" is still using prepared statements which was the goal of this test with --ps-protocol. mysql-test/t/query_cache.test: now that prepared statements work with the query cache, we check that results in binary protocol (prepared statements) and in text protocol (normal queries) don't mix in the query cache even though the text of the statement/query are identical. sql/mysql_priv.h: In class Query_cache_flags, we add a bit to say if the result is in binary or text format (because, a result in binary format should never be served to a query expecting text format, and vice- versa). A macro to emphasize that we read the size of the query cache without mutex ("maybe" word). A macro which gives a first indication of if a query is cache-able (first indication - it does not consider the query cache's state). sql/protocol.cc: indentation. sql/protocol.h: Children classes of Protocol report their type (currently, text or binary). Query cache needs to know that. sql/sql_cache.cc: When we store a result in the query cache, we need to remember if it's in binary or text format. And when we search for a result in the query cache, we need to select only those results which are in the format which the current statement expects (binary or text). sql/sql_prepare.cc: Enabling use of the query cache by prepared statements. 1) Prep stmts are of two types: a) prepared via the mysql_stmt_prepare() API call b) prepared via the SQL PREPARE...FROM statement. 2) We already, when executing a prepared statement, sometimes built an "expanded" statement. For a), "?" placeholders were replaced by their values. For b), by names of the user variables containing the values. We did that only when we needed to write the query to logs. We now use this expanded query also for storing/searching in the query cache. Assume a query "SELECT * FROM T WHERE c=?", and the parameter is 10. For a), the expanded query is "SELECT * FROM T WHERE c=10", we look for "SELECT * FROM T WHERE c=10" in the query cache, and store that query's result in the query cache. For b), the expanded query is "SELECT * FROM T WHERE c=@somevar", and user variables don't work with the query cache (even inside non- prepared queries), so we don't enable query caching for SQL PREPARE'd statements if they have at least one parameter (see "if (stmt->param_count > 0)" in the patch). 3) If query cache is enabled and this is a SELECT, we build the expanded query (as an optimisation, we don't want to build this expanded query if the query cache is disabled or this is not a SELECT). As the decision of building the expanded query or not is taken at prepare time (setup_set_params()), if query cache is disabled at prepare time, we won't build the expanded query at all next executions, thus shouldn't use this query for query cacheing. To ensure that we don't, we set safe_to_cache_query to FALSE. Note that we read the size of the query cache without mutex, which is ok: if we see it 0 but that cache has just been enlarged, no big deal, just our statement will not use the query cache; if we see it >0 but that cache has just been made destroyed, we'll build the expanded query at all executions, but query_cache_store_query() and query_cache_send_result_to_client() will read the size with a mutex and so properly decide to cache or not cache. 4) Some functions in this file were named "withlog", others "with_log", now using "with_log" for all. tests/mysql_client_test.c: Testing of how prepared statements enter and hit the query cache. test_ps_query_cache() is inspired from test_ps_conj_select(). It creates data, a prepared SELECT statement, executes it once, then a second time with the same parameter value, to see that cache is hit, then a 3rd time with another parameter value to see that cache is not hit. Then, same from another connection, expecting hits. Then, tests border cases (enables query cache at prepare and disables at execute and vice-versa). It checks all results of SELECTs, cache hits and misses. mysql-test/r/query_cache_sql_prepare.result: result of new test: we see hits when there is no parameter, no hit when there is a parameter. mysql-test/t/query_cache_sql_prepare.test: new test to see if SQL PREPARE'd statements enter/hit the query cache: - if having at least one parameter, they should not - if having zero parameters, they should.	19 years ago
unknown	e85102684e	Bug #26825 MySQL Server Crashes in high load Bug #26997 mysqld segfault when in single user mode sql/ha_ndbcluster.cc: make sure error is always set even if no proper error code from ndb storage/ndb/src/ndbapi/NdbDictionaryImpl.cpp: add error code for failing send signal (typically single user mode) storage/ndb/src/ndbapi/ndberror.c: added error code for failing send signal and timeout waiting for node failure	19 years ago
unknown	ff79cd6870	WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified 5.0 part of the fix. Implements IGNORE INDEX FOR JOIN as a synonym of IGNORE INDEX for backward compatibility with the 5.1 fix. mysql-test/r/select.result: WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified - test case mysql-test/t/select.test: WL#3527: Extend IGNORE INDEX so places where index is ignored can be specified - test case	19 years ago
unknown	febb6b924e	Resolve one shift/reduce conflict introduced with the push of the fix for bug#16425: Events: no DEFINER clause. The problem was that there were two rules ALTER view_algorithm_opt definer ... VIEW ... ALTER definer EVENT ... so when there was 'ALTER definer' in the input it was unclear if empty view_algorithm_opt should be executed or not. We solve this by introducing three distinct rules ALTER view_algorithm definer ... VIEW ... ALTER definer ... VIEW ... ALTER definer EVENT ... that remove the ambiguity. mysql-test/r/view.result: Add result for the test of ALTER ALGORITHM= DEFINER= VIEW. mysql-test/t/view.test: Add test case for ALTER ALGORITHM= DEFINER= VIEW.	19 years ago
unknown	29b6d55402	Bug #26281 : Fixed boundry checks in the INSERT() function: were one off. mysql-test/r/func_str.result: Bug #26281: test case mysql-test/t/func_str.test: Bug #26281: test case sql/item_strfunc.cc: Bug #26281: fixed boundry checks	19 years ago
unknown	0ea47f3ed4	BUG#9953: CONVERT_TZ requires mysql.time_zone_name to be locked The problem was that some facilities (like CONVERT_TZ() function or server HELP statement) may require implicit access to some tables in 'mysql' database. This access was done by ordinary means of adding such tables to the list of tables the query is going to open. However, if we issued LOCK TABLES before that, we would get "table was not locked" error trying to open such implicit tables. The solution is to treat certain tables as MySQL system tables, like we already do for mysql.proc. Such tables may be opened for reading at any moment regardless of any locks in effect. The cost of this is that system table may be locked for writing only together with other system tables, it is disallowed to lock system tables for writing and have any other lock on any other table. After this patch the following tables are treated as MySQL system tables: mysql.help_category mysql.help_keyword mysql.help_relation mysql.help_topic mysql.proc (it already was) mysql.time_zone mysql.time_zone_leap_second mysql.time_zone_name mysql.time_zone_transition mysql.time_zone_transition_type These tables are now opened with open_system_tables_for_read() and closed with close_system_tables(), or one table may be opened with open_system_table_for_update() and closed with close_thread_tables() (the latter is used for mysql.proc table, which is updated as part of normal MySQL server operation). These functions may be used when some tables were opened and locked already. NOTE: online update of time zone tables is not possible during replication, because there's no time zone cache flush neither on LOCK TABLES, nor on FLUSH TABLES, so the master may serve stale time zone data from cache, while on slave updated data will be loaded from the time zone tables. mysql-test/r/help.result: Update result. mysql-test/r/lock.result: Update result. mysql-test/r/sp-error.result: Update result. mysql-test/r/timezone2.result: Add result for bug#9953: CONVERT_TZ requires mysql.time_zone_name to be locked. mysql-test/r/view.result: Update result: use table t3 rather than utilize MySQL system table. mysql-test/t/help.test: Test that we can use HELP even under LOCK TABLES. mysql-test/t/lock.test: Test LOCK TABLE on system tables. mysql-test/t/timezone2.test: Add test case for bug#9953: CONVERT_TZ requires mysql.time_zone_name to be locked. mysql-test/t/view.test: Update test: use table t3 rather that utilize MySQL system table. sql/handler.h: Fix comment for 'count' parameter of check_if_locking_is_allowed(). Add 'current' and 'system_count' parameters. sql/item_create.cc: We no longer have LEX::add_time_zone_tables_to_query_tables(). sql/item_timefunc.cc: We no longer have LEX::time_zone_tables_used, so Item_func_convert_tz::fix_fields() became the same as base Item_date_func::fix_fields(). my_tz_find() no longer takes table list, but takes THD pointer now. sql/item_timefunc.h: Remove dead field and method. sql/lock.cc: Pass values for 'current' and 'system_count' to check_if_locking_is_allowed(). sql/log_event.cc: We no longer have my_tz_find_with_opening_tz_tables(), its functions is performed by my_tz_find(). sql/mysql_priv.h: Add functions to work with MySQL system tables. sql/set_var.cc: my_tz_find() no longer takes table list, but takes THD pointer now. sql/sp.cc: Remove close_proc_table(). Use close_system_tables() instead. Use open_system_tables_for_read() and open_system_table_for_update(). sql/sp.h: Remove close_proc_table() declaration. sql/sql_base.cc: Add implementation of open_system_tables_for_read(), close_system_tables(), open_system_table_for_update(). sql/sql_help.cc: Operate on MySQL system tables mysql.help_* with open_system_tables_for_read() and close_system_tables() to allow the usage of HELP statement under LOCK TABLES. sql/sql_lex.cc: Remove LEX::time_zone_tables_used and LEX::add_time_zone_tables_to_query_tables() which are no longer used. sql/sql_lex.h: Remove LEX::time_zone_tables_used and LEX::add_time_zone_tables_to_query_tables() which are no longer used. sql/sql_parse.cc: Remove references to LEX::time_zone_tables_used and my_tz_check_n_skip_implicit_tables() which are no longer used. sql/sql_show.cc: Use close_system_tables() instead of removed close_proc_table(). sql/sql_view.cc: LEX::time_zone_tables_used is no longer there. sql/sql_yacc.yy: LEX::add_time_zone_tables_to_query_tables() is no longer there. sql/table.cc: Add more tables that should be treated as MySQL system tables. sql/share/errmsg.txt: Change the error message, as now we allow write-locking of several system tables if not mixed with ordinary tables. sql/tztime.cc: Do not add time zone tables to the list of query tables in tz_init_table_list(). Remove fake_time_zone_tables_list and my_tz_get_tables_list(). In my_tz_init(), open mysql.time_zone_leap_second with simple_open_n_lock_tables(), but pass time zone name to my_tz_find(), which will open and close time zone tables as necessary. In tz_load_from_open_tables() do not call table->use_all_columns(), as this was already done in open_system_tables_for_read(). my_tz_find() takes THD pointer instead of table list, and calls open_system_tables_for_read() and close_system_tables() as necessary. Remove my_tz_find_with_opening_tz_tables(). sql/tztime.h: Remove declarations of my_tz_get_table_list(), my_tz_find_with_opening_tz_tables(), fake_time_zone_tables_list, definition of my_tz_check_n_skip_implicit_tables(). Update prototype for my_tz_find(). storage/csv/ha_tina.cc: Add new parameters to check_if_locking_is_allowed(). storage/csv/ha_tina.h: Add new parameters to check_if_locking_is_allowed(). storage/myisam/ha_myisam.cc: Add new parameters to check_if_locking_is_allowed(). In this function we count system tables. If there are system tables, but there are also non-system tables, we report an error. storage/myisam/ha_myisam.h: Add new parameters to check_if_locking_is_allowed().	19 years ago
unknown	729bcaf430	Fixed bug #26661 : crash when order by clause in a union construct references invalid name. Derived tables currently cannot use outer references. Thus there is no outer context for them. The 4.1 code takes this fact into account while the Item_field::fix_outer_field code of 5.0 lost the check that blocks any attempts to resolve names in outer context for derived tables. mysql-test/r/union.result: Added a test case for bug #26661. mysql-test/t/union.test: Added a test case for bug #26661. sql/item.cc: Fixed bug #26661. Derived tables currently cannot use outer references. Thus there is no outer context for them. The 4.1 code takes this fact into account while the Item_field::fix_outer_field code of 5.0 lost the check that blocks any attempts to resolve names in outer context for derived tables.	19 years ago
unknown	264bcedd7e	Fix typo.	19 years ago
unknown	a0521cd749	Polishing: use constants instead of magic numbers. include/my_global.h: Introduce constants to be used instead of magic numbers. sql/field.cc: Polishing: use contants instead of magic numbers. sql/ha_innodb.cc: Polishing: use contants instead of magic numbers. sql/handler.cc: Polishing: use contants instead of magic numbers. sql/item.cc: Polishing: use contants instead of magic numbers. sql/item.h: Polishing: use contants instead of magic numbers. sql/item_func.cc: Polishing: use contants instead of magic numbers. sql/item_subselect.cc: Polishing: use contants instead of magic numbers. sql/log_event.cc: Polishing: use contants instead of magic numbers. sql/sql_base.cc: Polishing: use contants instead of magic numbers. sql/sql_select.cc: Polishing: use contants instead of magic numbers. sql/sql_show.cc: Polishing: use contants instead of magic numbers. sql/sql_table.cc: Polishing: use contants instead of magic numbers.	19 years ago
unknown	4c0ab891ea	sql_select.cc: Postfix for bug#22331. sql/sql_select.cc: Postfix for bug#22331.	19 years ago
unknown	10ddaa7853	Fix 6 warnings from win64, where one is a potential bug. sql/event_data_objects.cc: Passing time as time_t to function my_time_t requires cast to my_time_t since my_time_t are only required to be 32bits. sql/log.cc: Using time_t instead of my_time_t when calculating current_time. This is a potential bugfix for problem with mysql_system_db reporting slow log as crashed. sql/sql_show.cc: Passing time as time_t to function my_time_t requires cast to my_time_t since my_time_t are only required to be 32bits.	19 years ago
unknown	b33780693c	Fix -ansi -pedantic warning (can't cast a pointer to function to a pointer to object, that is, int foo(); void bar= (void) foo is not allowed. sql/lex.h: Fix -ansi -pedantic warning. sql/lex_symbol.h: Fix -ansi -pedantic warning.	19 years ago
unknown	441cae6996	Bug #26940 : CREATE SERVER does not initialize record[0] in insert_server_record() sql_servers.cc:insert_server_record(): initialize record[0] before inserting row sql/sql_servers.cc: sql_servers.cc:insert_server_record(): initialize record[0] before inserting row	19 years ago
unknown	1631f65dfd	sql_select.cc: Postfix for bug#22331 for windows platform. explain.test, explain.result: Cleanup after bugfix#22331. mysql-test/t/explain.test: Cleanup after bugfix#22331. mysql-test/r/explain.result: Cleanup after bugfix#22331. sql/sql_select.cc: Postfix for bug#22331 for windows platform.	19 years ago
unknown	11b533b8be	Bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. For built-in functions like sqrt() function names are hard-coded and can be compared by pointer. But this isn't the case for a used-defined stored functions - names there are dynamical and should be compared as strings. Now the Item_func::eq() function employs my_strcasecmp() function to compare used-defined stored functions names. mysql-test/t/sp.test: Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. mysql-test/r/sp.result: Added a test case for bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. sql/item_func.cc: Bug#25373: Stored functions wasn't compared correctly which leads to a wrong result. Now the Item_func::eq() function employs my_strcasecmp() function to compare used-defined stored functions names.	19 years ago

1 2 3 4 5 ...

20104 Commits (57dc12563f099c7802ea8eaeb0c52ac4082de67a)