mariadb

Commit Graph

Author	SHA1	Message	Date
Oleksandr Byelkin	4fc9dc84b0	MDEV-32086 (part 2) Server crash when inserting from derived table containing insert target table Get rid of need of matherialization for usual INSERT (cache results in Item_cache* if needed) - subqueries in VALUE do not see new records in the table we are inserting to - subqueries in RETIRNING prohibited to use the table we are inserting to	6 months ago
Brandon Nesterenko	d8c841d0d4	MDEV-35096: History is stored in different partitions on different nodes when using SYSTEM VERSION Row-injection updates don’t correctly set the historical partition for tables with system versioning and system_time partitions. This results in inconsistencies between the master and slave when replicating transactions that target such tables (i.e. the primary server would correctly distribute archived rows amongst its partitions, whereas the replica would have all archived rows in a single partition). The function partition_info::vers_set_hist_part(THD) is used to set the partition; however, its initial check for vers_require_hist_part(THD) returns false, bypassing the rest of the function (which sets up the partition to use). This is because the actual check uses the LEX sql_command (via LEX::vers_history_generating()) to determine if the command is valid to generate history. Row injections don’t have sql_commands though. This patch provides a fix which extends the check in vers_history_generating() to additionally allow row injections to be history generating (via the function LEX::is_stmt_row_injection()). Special thanks to Jan Lindstrom <jan.lindstrom@galeracluster.com> for his work in reproducing the bug, and providing an initial test case. Reviewed By ============ Kristian Nielsen <knielsen@knielsen-hq.org> Aleksey Midenkov <midenok@mariadb.com>	9 months ago
Oleksandr Byelkin	8d810e9426	MDEV-29537 Creation of view with UNION and SELECT ... FOR UPDATE in definition is failed with error lock_type is writen in the last SELECT of the unit even if it parsed last, so it should be printed last from the last select of the unit.	1 year ago
Yuchen Pei	2c3e07df47	MDEV-34447: Memory leakage is detected on running the test main.ps against the server 11.1 The memory leak happened on second execution of a prepared statement that runs UPDATE statement with correlated subquery in right hand side of the SET clause. In this case, invocation of the method table->stat_records() could return the zero value that results in going into the 'if' branch that handles impossible where condition. The issue is that this condition branch missed saving of leaf tables that has to be performed as first condition optimization activity. Later the PS statement memory root is marked as read only on finishing first time execution of the prepared statement. Next time the same statement is executed it hits the assertion on attempt to allocate a memory on the PS memory root marked as read only. This memory allocation takes place by the sequence of the following invocations: Prepared_statement::execute mysql_execute_command Sql_cmd_dml::execute Sql_cmd_update::execute_inner Sql_cmd_update::update_single_table st_select_lex::save_leaf_tables List<TABLE_LIST>::push_back To fix the issue, add the flag SELECT_LEX::leaf_tables_saved to control whether the method SELECT_LEX::save_leaf_tables() has to be called or it has been already invoked and no more invocation required. Similar issue could take place on running the DELETE statement with the LIMIT clause in PS/SP mode. The reason of memory leak is the same as for UPDATE case and be fixed in the same way.	1 year ago
Rex	9e800eda86	MDEV-32583 UUID() should be treated as stochastic for the purposes of forcing query materialization RAND() and UUID() are treated differently with respect to subquery materialization both should be marked as uncacheable, forcing materialization. Altered Create_func_uuid(_short)::create_builder(). Added comment in header about UNCACHEABLE_RAND meaning also unmergeable.	2 years ago
Dmitry Shulga	5e6c122427	MDEV-33769: Memory leak found in the test main.rownum run with --ps-protocol against a server built with the option -DWITH_PROTECT_STATEMENT_MEMROOT A memory leak happens on the second execution of a query that run in PS mode and uses the function ROWNUM(). A memory leak took place on allocation of an instance of the class Item_int for storing a limit value that is performed at the function set_limit_for_unit indirectly called from JOIN::optimize_inner. Typical trace to the place where the memory leak occurred is below: JOIN::optimize_inner optimize_rownum process_direct_rownum_comparison set_limit_for_unit new (thd->mem_root) Item_int(thd, lim, MAX_BIGINT_WIDTH); To fix this memory leak, calling of the function optimize_rownum() has to be performed only once on first execution and never called after that. To control it, the new data member first_rownum_optimization added into the structure st_select_lex.	1 year ago
Marko Mäkelä	09d991d01c	MDEV-33478: Tests massively fail with clang-18 -fsanitize=memory Starting with clang-16, MemorySanitizer appears to check that uninitialized values not be passed by value nor returned. Previously, it was allowed to copy uninitialized data in such cases. get_foreign_key_info(): Remove a local variable that was passed uninitialized to a function. DsMrr_impl: Initialize key_buffer, because DsMrr_impl::dsmrr_init() is reading it. test_bind_result_ext1(): MYSQL_TYPE_LONG is 32 bits, hence we must use a 32-bit type, such as int. sizeof(long) differs between LP64 and LLP64 targets.	2 years ago
Igor Babaev	54ed3939f7	MDEV-31657 Crash on query using CTE with the same name as a base table If a query contained a CTE whose name coincided with the name of one of the base tables used in the specification of the CTE and the query had at least two references to this CTE in the specifications of other CTEs then processing of the query led to unlimited recursion that ultimately caused a crash of the server. Any secondary non-recursive reference to a CTE requires creation of a copy of the CTE specification. All the references to CTEs in this copy must be resolved. If the specification contains a reference to a base table whose name coincides with the name of then CTE then it should be ensured that this reference in no way can be resolved against the name of the CTE.	2 years ago
Rex	2c1345ab27	MDEV-31995 Fix2 allocate memory in mem_root properly. Lex_ident_sys had no new operator and was used incorrectly in save_item_list_names(), so leaked memory.	2 years ago
Rex	8b509a5d64	Merge 10.4 into 10.5	2 years ago
Alexander Barkov	2b6d241ee4	MDEV-27744 LPAD in vcol created in ORACLE mode makes table corrupted in non-ORACLE The crash happened with an indexed virtual column whose value is evaluated using a function that has a different meaning in sql_mode='' vs sql_mode=ORACLE: - DECODE() - LTRIM() - RTRIM() - LPAD() - RPAD() - REPLACE() - SUBSTR() For example: CREATE TABLE t1 ( b VARCHAR(1), g CHAR(1) GENERATED ALWAYS AS (SUBSTR(b,0,0)) VIRTUAL, KEY g(g) ); So far we had replacement XXX_ORACLE() functions for all mentioned function, e.g. SUBSTR_ORACLE() for SUBSTR(). So it was possible to correctly re-parse SUBSTR_ORACLE() even in sql_mode=''. But it was not possible to re-parse the MariaDB version of SUBSTR() after switching to sql_mode=ORACLE. It was erroneously mis-interpreted as SUBSTR_ORACLE(). As a result, this combination worked fine: SET sql_mode=ORACLE; CREATE TABLE t1 ... g CHAR(1) GENERATED ALWAYS AS (SUBSTR(b,0,0)) VIRTUAL, ...; INSERT ... FLUSH TABLES; SET sql_mode=''; INSERT ... But the other way around it crashed: SET sql_mode=''; CREATE TABLE t1 ... g CHAR(1) GENERATED ALWAYS AS (SUBSTR(b,0,0)) VIRTUAL, ...; INSERT ... FLUSH TABLES; SET sql_mode=ORACLE; INSERT ... At CREATE time, SUBSTR was instantiated as Item_func_substr and printed in the FRM file as substr(). At re-open time with sql_mode=ORACLE, "substr()" was erroneously instantiated as Item_func_substr_oracle. Fix: The fix proposes a symmetric solution. It provides a way to re-parse reliably all sql_mode dependent functions to their original CREATE TABLE time meaning, no matter what the open-time sql_mode is. We take advantage of the same idea we previously used to resolve sql_mode dependent data types. Now all sql_mode dependent functions are printed by SHOW using a schema qualifier when the current sql_mode differs from the function sql_mode: SET sql_mode=''; CREATE TABLE t1 ... SUBSTR(a,b,c) ..; SET sql_mode=ORACLE; SHOW CREATE TABLE t1; -> mariadb_schema.substr(a,b,c) SET sql_mode=ORACLE; CREATE TABLE t2 ... SUBSTR(a,b,c) ..; SET sql_mode=''; SHOW CREATE TABLE t1; -> oracle_schema.substr(a,b,c) Old replacement names like substr_oracle() are still understood for backward compatibility and used in FRM files (for downgrade compatibility), but they are not printed by SHOW any more.	4 years ago
Rex	eb8053b377	MDEV-31995 Bogus error executing PS for query using CTE with renaming of columns This commit addresses column naming issues with CTEs in the use of prepared statements and stored procedures. Usage of either prepared statements or procedures with Common Table Expressions and column renaming may be affected. There are three related but different issues addressed here. 1) First execution issue. Consider the following prepare s from "with cte (col1, col2) as (select a as c1, b as c2 from t order by c1) select col1, col2 from cte"; execute s; After parsing, items in the select are named (c1,c2), order by (and group by) resolution is performed, then item names are set to (col1, col2). When the statement is executed, context analysis is again performed, but resolution of elements in the order by statement will not be able to find c1, because it was renamed to col1 and remains this way. The solution is to save the names of these items during context resolution before they have been renamed. We can then reset item names back to those after parsing so first execution can resolve items referred to in order and group by clauses. 2) Second Execution Issue When the derived table contains more than one select 'unioned' together we could reasonably think that dealing with only items in the first select (which determines names in the resultant table) would be sufficient. This can lead to a different problem. Consider prepare st from "with cte (c1,c2) as (select a as col1, sum(b) as col2 from t1 where a > 0 group by col1 union select a as col3, sum(b) as col4 from t2 where b > 2 group by col3) select * from cte where c1=1"; When the optimizer (only run during the first execution) pushes the outside condition "c1=1" into every select in the derived table union, it renames the items to make the condition valid. In this example, this leaves the first item in the second select named 'c1'. The second execution will now fail 'group by' resolution. Again, the solution is to save the names during context analysis, resetting before subsequent resolution, but making sure that we save/reset the item names in all the selects in this union. 3) Memory Leak During parsing Item::set_name() is used to allocate memory in the statement arena. We cannot use this call during statement execution as this represents a memory leak. We directly set the item list names to those in the column list of this CTE (also allocated during parsing). Approved by Igor Babaev <igor@mariadb.com>	2 years ago
Alexander Barkov	534a2bf1c6	MDEV-32275 getting error 'Illegal parameter data types row and bigint for operation '+' ' when using ITERATE in a FOR..DO An "ITERATE innerLoop" did not work properly inside a WHILE loop, which itself is inside an outer FOR loop: outerLoop: FOR ... innerLoop: WHILE ... ITERATE innerLoop; ... END WHILE; ... END FOR; It erroneously generated an integer increment code for the outer FOR loop. There were two problems: 1. "ITERATE innerLoop" worked like "ITERATE outerLoop" 2. It was always integer increment, even in case of FOR cursor loops. Background: - A FOR loop automatically creates a dedicated sp_pcontext stack entry, to put the iteration and bound variables on it. - Other loop types (LOOP, WHILE, REPEAT), do not generate a dedicated slack entry. The old code erroneously assumed that sp_pcontext::m_for_loop either describes the most inner loop (in case the inner loop is FOR), or is empty (in case the inner loop is not FOR). But in fact, sp_pcontext::m_for_loop is never empty inside a FOR loop: it describes the closest FOR loop, even if this FOR loop has nested non-FOR loops inside. So when we're near the ITERATE statement in the above script, sp_pcontext::m_for_loop is not empty - it stores information about the FOR loop labeled as "outrLoop:". Fix: - Adding a new member sp_pcontext::Lex_for_loop::m_start_label, to remember the explicit or the auto-generated label correspoding to the start of the FOR body. It's used during generation of "ITERATE loop_label" code to check if "loop_label" belongs to the current FOR loop pointed by sp_pcontext::m_for_loop, or belongs to a non-FOR nested loop. - Adding LEX methods sp_for_loop_intrange_iterate() and sp_for_loop_cursor_iterate() to reuse the code between methods handling: * ITERATE * END FOR - Adding a test for Lex_for_loop::is_for_loop_cursor() and generate a code either a cursor fetch, or for an integer increment. Before this change, it always erroneously generated an integer increment version. - Cleanup: Initialize Lex_for_loop_st::m_cursor_offset inside Lex_for_loop_st::init(), to avoid not initialized members. - Cleanup: Removing a redundant method: Lex_for_loop_st::init(const Lex_for_loop_st &other) Using Lex_for_loop_st::operator(const Lex_for_loop_st &other) instead.	2 years ago
Igor Babaev	4e2594768d	MDEV-32259 Test from win.test fails with statement memory protection The function setup_windows() called at the prepare phase of processing a select builds a list of all window specifications used in the select. This list is built on the statement memory and it must be done only once. Approved by Oleksandr Byelkin <sanja@mariadb.com>	2 years ago
Igor Babaev	47f0135d7a	MDEV-32245 Test from subselect.test fails with statement memory protection With this patch st_select_lex::ref_pointer_array is never re-allocated. Approved by Oleksandr Byelkin <sanja@mariadb.com>	2 years ago
Alexander Barkov	400c101332	MDEV-30662 SQL/PL package body does not appear in I_S.ROUTINES.ROUTINE_DEFINITION - Moving the code from a public function trim_whitespaces() to the class Lex_cstring as methods. This code may be useful in other contexts, and also this code becomes visible inside sql_class.h - Adding a helper method THD::strmake_lex_cstring_trim_whitespaces() - Unifying the way how CREATE PROCEDURE/CREATE FUNCTION and CREATE PACKAGE/CREATE PACKAGE BODY work: a) Now CREATE PACKAGE/CREATE PACKAGE BODY also calls Lex->sphead->set_body_start() to remember the cpp body start inside an sp_head member. b) adding a "const char *cpp_body_end" parameter to sp_head::set_stmt_end(). These changes made it possible to reuse sp_head::set_stmt_end() inside LEX::create_package_finalize() and remove the duplucate code. - Renaming sp_head::m_body_begin to m_cpp_body_begin and adding a comment to make it clear that this member is used only during parsing, and points to a fragment inside the cpp buffer. - Changed sp_head::set_body_start() and sp_head::set_stmt_end() to skip the calls related to "body_utf8" in cases when m_parent is not NULL. A non-NULL m_parent means that we're inside a package routine. "body_utf8" in such case belongs not to the current sphead itself, but to parent (the package) sphead. So an sphead instance of a package routine should neither initialize, nor finalize, nor change in any other ways the "body_utf8" related members of Lex_input_stream, and should not take over or copy "body_utf8" data from Lex_input_stream to "this".	2 years ago
Monty	99bd226059	MDEV-31558 Add InnoDB engine information to the slow query log The new statistics is enabled by adding the "engine", "innodb" or "full" option to --log-slow-verbosity Example output: # Pages_accessed: 184 Pages_read: 95 Pages_updated: 0 Old_rows_read: 1 # Pages_read_time: 17.0204 Engine_time: 248.1297 Page_read_time is time doing physical reads inside a storage engine. (Writes cannot be tracked as these are usually done in the background). Engine_time is the time spent inside the storage engine for the full duration of the read/write/update calls. It uses the same code as 'analyze statement' for calculating the time spent. The engine statistics is done with a generic interface that should be easy for any engine to use. It can also easily be extended to provide even more statistics. Currently only InnoDB has counters for Pages_% and Undo_% status. Engine_time works for all engines. Implementation details: class ha_handler_stats holds all engine stats. This class is included in handler and THD classes. While a query is running, all statistics is updated in the handler. In close_thread_tables() the statistics is added to the THD. handler::handler_stats is a pointer to where statistics should be collected. This is set to point to handler::active_handler_stats if stats are requested. If not, it is set to 0. handler_stats has also an element, 'active' that is 1 if stats are requested. This is to allow engines to avoid doing any 'if's while updating the statistics. Cloned or partition tables have the pointer set to the base table if status are requested. There is a small performance impact when using --log-slow-verbosity=engine: - All engine calls in 'select' will be timed. - IO calls for InnoDB reads will be timed. - Incrementation of counters are done on local variables and accesses are inline, so these should have very little impact. - Statistics has to be reset for each statement for the THD and each used handler. This is only 40 bytes, which should be neglectable. - For partition tables we have to loop over all partitions to update the handler_status as part of table_init(). Can be optimized in the future to only do this is log-slow-verbosity changes. For this to work we have to update handler_status for all opened partitions and also for all partitions opened in the future. Other things: - Added options 'engine' and 'full' to log-slow-verbosity. - Some of the new files in the test suite comes from Percona server, which has similar status information. - buf_page_optimistic_get(): Do not increment any counter, since we are only validating a pointer, not performing any buf_pool.page_hash lookup. - Added THD argument to save_explain_data_intern(). - Switched arguments for save_explain_.*_data() to have always THD first (generates better code as other functions also have THD first).	2 years ago
Alexander Barkov	29bc61912e	A cleanup for MDEV-31578 DECLARE CURSOR: "Memory not freed: 280 bytes lost" on syntax error Removing the method LEX::delete_if_not_sp_lex_in_use(). It was not really used.	2 years ago
Alexander Barkov	fdab2c4c64	MDEV-31578 DECLARE CURSOR: "Memory not freed: 280 bytes lost" on syntax error When CURSOR parameters get parsed, their sp_assignment_lex instances (one instance per parameter) get collected to List<sp_assignment_lex>. These instances get linked to sphead only in the end of the list. If a syntax error happened in the middle of the parameter list, these instances were not deleted, which caused memory leaks. Fix: using a Bison %destructor to free rules of the <sp_assignment_lex_list> type (on syntax errors). Afte the fix these sp_assignment_lex instances from CURSOR parameters deleted as follows: - If the CURSOR statement was fully parsed, then these instances get properly linked to sp_head structures, so they are deleted during ~sp_head (this did not change) - If the CURSOR statement failed on a syntax error, then by Bison's %destructor (this is being added in the current patch).	2 years ago
Igor Babaev	fe89df4268	MDEV-31162 Crash for query using ROWNUM over multi-table view with ORDER BY This bug could cause a crash of the server when processing a query with ROWNUM() if it used in its FROM list a reference to a mergeable view defined as SELECT over more than one table that contained ORDER BY clause. When a mergeable view with ORDER BY clause and without LIMIT clause is used in the FROM list of a query that does not have ORDER BY clause the ORDER BY clause of the view is moved to the query. The code that performed this transformation forgot to delete the moved ORDER BY list from the view. If a query contains ROWNUM() and uses a mergeable multi-table view with ORDER BY then according to the current code of TABLE_LIST::init_derived() the view has to be forcibly materialized. As the query and the view shared the same items in its ORDER BY lists they could not be properly resolved either in the query or in the view. This led to a crash of the server. This patch has returned back the original signature of LEX::can_not_use_merged() to comply with 10.4 code of the condition that checks whether a megeable view has to be forcibly materialized. Approved by Oleksandr Byelkin <sanja@mariadb.com>	3 years ago
Alexander Barkov	ddcc9d2281	MDEV-31153 New methods Schema::make_item_func_* for REPLACE, SUBSTRING, TRIM Adding virtual methods to class Schema: make_item_func_replace() make_item_func_substr() make_item_func_trim() This is a non-functional preparatory change for MDEV-27744.	3 years ago
Alexander Barkov	2e74f9d281	Adding "const" qualifiers to a few trivial Lex_input_string methods	3 years ago
Oleksandr Byelkin	2eb7bf1ec3	MDEV-31073 Server crash, assertion `table != 0 && view->field_translation != 0' failure with ROWNUM and view Now the same rule applied to vews and derived tables. So we should allow merge of views (and derived) in queries with rownum, because it do not change results, only makes query plans better.	3 years ago
Igor Babaev	f33fc2fae5	MDEV-30539 EXPLAIN EXTENDED: no message with queries for DML statements EXPLAIN EXTENDED for an UPDATE/DELETE/INSERT/REPLACE statement did not produce the warning containing the text representation of the query obtained after the optimization phase. Such warning was produced for SELECT statements, but not for DML statements. The patch fixes this defect of EXPLAIN EXTENDED for DML statements.	3 years ago
Igor Babaev	ccec9b1de9	MDEV-30706 Different results of selects from view and CTE with same definition MDEV-30668 Set function aggregated in outer select used in view definition This patch fixes two bugs concerning views whose specifications contain subqueries with set functions aggregated in outer selects. Due to the first bug those such views that have implicit grouping were considered as mergeable. This led to wrong result sets for selects from these views. Due to the second bug the aggregation select was determined incorrectly and this led to bogus error messages. The patch added several test cases for these two bugs and for four other duplicate bugs. The patch also enables view-protocol for many other test cases. Approved by Oleksandr Byelkin <sanja@mariadb.com>	3 years ago
Igor Babaev	841e8877cc	MDEV-28603 Invalid view when its definition uses TVC as single-value subquery Subselect_single_value_engine cannot handle table value constructor used as subquery. That's why any table value constructor TVC used as subquery is converted into a select over derived table whose specification is TVC. Currently the names of the columns of the derived table DT are taken from the first element of TVC and if the k-th component of the element happens to be a subquery the text representation of this subquery serves as the name of the k-th column of the derived table. References of all columns of the derived table DT compose the select list of the result of the conversion. If a definition of a view contained a table value constructor used as a subquery and the view was registered after this conversion had been applied we could register an invalid view definition if the first element of TVC contained a subquery as its component: the name of this component was taken from the original subquery, while the name of the corresponding column of the derived table was taken from the text representation of the subquery produced by the function SELECT_LEX::print() and these names were usually differ from each other. To avoid registration of such invalid views the function SELECT_LEX::print() now prints the original TVC instead of the select in which this TVC has been wrapped. Now the specification of registered view looks like as if no conversions from TVC to selects were done. Approved by Oleksandr Byelkin <sanja@mariadb.com>	3 years ago
Vicențiu Ciorbaru	08c852026d	Apply clang-tidy to remove empty constructors / destructors This patch is the result of running run-clang-tidy -fix -header-filter=.* -checks='-,modernize-use-equals-default' . Code style changes have been done on top. The result of this change leads to the following improvements: 1. Binary size reduction. For a -DBUILD_CONFIG=mysql_release build, the binary size is reduced by ~400kb. * A raw -DCMAKE_BUILD_TYPE=Release reduces the binary size by ~1.4kb. 2. Compiler can better understand the intent of the code, thus it leads to more optimization possibilities. Additionally it enabled detecting unused variables that had an empty default constructor but not marked so explicitly. Particular change required following this patch in sql/opt_range.cc result_keys, an unused template class Bitmap now correctly issues unused variable warnings. Setting Bitmap template class constructor to default allows the compiler to identify that there are no side-effects when instantiating the class. Previously the compiler could not issue the warning as it assumed Bitmap class (being a template) would not be performing a NO-OP for its default constructor. This prevented the "unused variable warning".	3 years ago
Igor Babaev	074bef4dca	MDEV-30248 Infinite sequence of recursive calls when processing embedded CTE This patch fixes the patch for bug MDEV-30248 that unsatisfactorily resolved the problem of resolution of references to CTE. In some cases when such a reference has the same table name as the name of one of CTEs containing this reference the reference could be resolved incorrectly that led to an invalid select tree where units could be mutually dependent. This in its turn could lead to an infinite sequence of recursive calls or to falls into infinite loops. The patch also removes LEX::resolve_references_to_cte_in_hanging_cte() as with the new code for resolution of CTE references the call of this function is not needed anymore. Approved by Oleksandr Byelkin <sanja@mariadb.com>	3 years ago
Igor Babaev	ea270178b0	MDEV-30052 Crash with a query containing nested WINDOW clauses Use SELECT_LEX to save lists for ORDER BY and GROUP BY before parsing WINDOW clauses / specifications. This is needed for proper parsing of a nested WINDOW clause when a WINDOW clause is used in a subquery contained in another WINDOW clause. Fix assignment of empty SQL_I_List to another one (in case of empty list next shoud point on first).	3 years ago
Sergei Golubchik	cce76fef38	ADD CONSTRAINT IF NOT EXISTS didn't work in SP "if not exists" must be stored in a separate read-only property	3 years ago
Sergei Petrunia	e0dbec1ce3	MDEV-29129: Performance regression starting in 10.6: select order by limit ... The cause of regression was handling for ROWNUM() function. For queries like SELECT ROWNUM() FROM ... ORDER BY ... ROWNUM() should be computed before the ORDER BY. The computation was moved to be before the ORDER BY for any entries in the select list that had RAND_TABLE_BIT set. This had a negative impact on queries in form: SELECT sp_func() FROM t1 ORDER BY ... LIMIT n where sp_func() is NOT declared as DETERMINISTIC (and so has RAND_TABLE_BIT set). The fix is to require evaluation for sorting only for the ROWNUM() function. Functions that just have RAND_TABLE_BIT() can be computed after ORDER BY ... LIMIT is applied. (think about a possible index that satisfies the ORDER BY clause. In that case, the the rows would be read in the needed order and we would stop after reading LIMIT rows, achieving the same effect).	3 years ago
Oleksandr Byelkin	47e9678982	MDEV-29022 add_slave destroy child list and has dead code Nowdays subquery in a UNION's ORDER BY placed correctly in fake select, the only problem was incorrect Name_resolution_contect is fixed by this patch in parsing, so we do not need scanning/reseting of ORDER BY of a union.	3 years ago
tmokmss	827b049e1e	MDEV-18873 Server crashes in Compare_identifiers::operator or in my_strcasecmp_utf8 upon ADD PERIOD IF NOT EXISTS with empty name empty identifier specified as `` ends up with a NULL LEX_CSTRING::str in lexer. This is not considered correct in upper layers, for example in Compare_identifiers::operator(). Empty column name is usually avoided by a check_column_name() call while parsing, and period name matches the column name completely. Hence, this fix uses the mentioned call for verification, too.	3 years ago
Oleksandr Byelkin	92a3280998	table_count was present twice in one class of LEX. Remove table_count from Query_tables_list (not used, moved to MYSQL_LOCK). Rename table_count from LEX to avoid mixing it with other counters of tables.	3 years ago
Dmitry Shulga	f439cfdf93	MDEV-22001: Server crashes in st_select_lex_unit::exclude_level upon execution of SP Running some statements that use IN subqueries outside context of a regular query could result in server abnormal termination. The reason for failure is that internal structures SELECT_LEX/SELECT_LEX_UNIT created on behalf of parsed query were initialized incorrectly. Incorrect initialization of the structures SELECT_LEX/SELECT_LEX_UNIT was introduced by the commit `de745ecf29` (MDEV-11953: support of brackets in UNION/EXCEPT/INTERSECT operations) pushed into 10.4, that is the reason this bug report is not reproduced in 10.3. To fix the issue the method SLECTE_LEX::register_unit is used for proper initialization of the data structures SELECT_LEX/SELECT_LEX_UNIT. Additionally, the method SELECT_LEX::get_slave() was removed from the source code base since for those use cases where it is used it can be replaced by the method first_inner_unit().	3 years ago
Sergei Golubchik	29c07643a1	enable -Wenum-compare -Wenum-conversion to make the all headers -std=c++20 clean for those, who need c++20 (some plugins)	4 years ago
Igor Babaev	6e7c6fcfd1	MDEV-28448 Assertion failure for SELECT with subquery using ON expression This patch corrects the fix for MDEV-26412. Note that when parsing an ON expression the pointer to the current select is always in select_stack[select_stack_top - 1]. So the pointer to the outer select (if any) is in select_stack[select_stack_top - 2]. The query manifesting this bug is added to the test case of MDEV-26412.	4 years ago
Aleksey Midenkov	ddc416c606	MDEV-20077 Warning on full history partition is delayed until next DML statement Moved LIMIT warning from vers_set_hist_part() to new call vers_check_limit() at table unlock phase. At that point read_partitions bitmap is already pruned by DML code (see prune_partitions(), find_used_partitions()) so we have to set corresponding bits for working history partition. Also we don't do my_error(ME_WARNING\|ME_ERROR_LOG), because at that point it doesn't update warnings number, so command reports 0 warnings (but warning list is still updated). Instead we do push_warning_printf() and sql_print_warning() separately. Under LOCK TABLES external_lock(F_UNLCK) is not executed. There is start_stmt(), but no corresponding "stop_stmt()". So for that mode we call vers_check_limit() directly from close_thread_tables(). Test result has been changed according to new LIMIT and warning printing algorithm. For convenience all LIMIT warnings are marked with "You see warning above ^". TODO MDEV-20345 fixed. Now vers_history_generating() contains fine-grained list of DML-commands that can generate history (and TODO mechanism worked well).	4 years ago
Igor Babaev	39feab3cd3	MDEV-26412 Server crash in Item_field::fix_outer_field for INSERT SELECT IF an INSERT/REPLACE SELECT statement contained an ON expression in the top level select and this expression used a subquery with a column reference that could not be resolved then an attempt to resolve this reference as an outer reference caused a crash of the server. This happened because the outer context field in the Name_resolution_context structure was not set to NULL for such references. Rather it pointed to the first element in the select_stack. Note that starting from 10.4 we cannot use the SELECT_LEX::outer_select() method when parsing a SELECT construct. Approved by Oleksandr Byelkin <sanja@mariadb.com>	4 years ago
Alexander Barkov	fbcf0225e1	MDEV-19804 sql_mode=ORACLE: call procedure in packages Adding support for the fully qualified package procedure calls: BEGIN CALL db.pkg.proc(args); -- SQL/PSM call style db.pkg.proc(args); -- PL/SQL call style END;	4 years ago
Alexander Barkov	6437b30404	MDEV-28166 sql_mode=ORACLE: fully qualified package function calls do not work: db.pkg.func() Also fixes MDEV-19328 sql_mode=ORACLE: Package function in VIEW	4 years ago
Vlad Lesin	1766a18e06	MDEV-19577 Replication does not work with innodb_autoinc_lock_mode=2 The first step for deprecating innodb_autoinc_lock_mode(see MDEV-27844) is: - to switch statement binlog format to ROW if binlog format is MIXED and the statement changes autoincremented fields - issue warnings if innodb_autoinc_lock_mode == 2 and binlog format is STATEMENT	4 years ago
Rucha Deodhar	fad1d15326	MDEV-25460: Assertion `!is_set() \|\| (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status in my_ok from mysql_sql_stmt_prepare Analysis: Before PREPARE is executed, binlog_format is STATEMENT. This PREPARE had SET STATEMENT which sets binlog_format to ROW. Now after PREPARE is done we reset the binlog_format (back to STATEMENT). But we have temporary table, it doesn't let changing binlog_format=ROW to binlog_format=STATEMENT and gives error which goes unreported. This unreported error eventually causes assertion failure. Fix: Change return type for LEX::restore_set_statement_var() to bool and make it return error state.	4 years ago
Igor Babaev	12c80df482	MDEV-20411 Procedure containing CTE incorrectly stored in mysql.proc If the first token of the body of a stored procedure was 'WITH' then the beginning of the body was determined incorrectly and that token was missing in the string representing the body of the SP in mysql.proc. As a resultnany call of such procedure failed as the string representing the body could not be parsed. The patch corrects the code of the functions get_tok_start() and get_cpp_tok_start() of the class Lex_input_stream to make them take into account look ahead tokens. The patch is needed only for 10.2 as this problem has neen resolved in 10.3+.	4 years ago
Dmitry Shulga	5478ca779a	MDEV-25576: The statement EXPLAIN running as regular statement and as prepared statement produces different results for UPDATE with subquery 10.6 cleanup	5 years ago
Dmitry Shulga	9370c6e83c	MDEV-16708: Unsupported commands for prepared statements Withing this task the following changes were made: - Added sending of metadata info in prepare phase for the admin related command (check table, checksum table, repair, optimize, analyze). - Refactored implmentation of HELP command to support its execution in PS mode - Added support for execution of LOAD INTO and XA- related statements in PS mode - Modified mysqltest.cc to run statements in PS mode unconditionally in case the option --ps-protocol is set. Formerly, only those statements were executed using PS protocol that matched the hard-coded regular expression - Fixed the following issues: The statement explain select (select 2) executed in regular and PS mode produces different results: MariaDB [test]> prepare stmt from "explain select (select 2)"; Query OK, 0 rows affected (0,000 sec) Statement prepared MariaDB [test]> execute stmt; +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ \| id \| select_type \| table \| type \| possible_keys \| key \| key_len \| ref \| rows \| Extra \| +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ \| 1 \| PRIMARY \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| No tables used \| \| 2 \| SUBQUERY \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| No tables used \| +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ 2 rows in set (0,000 sec) MariaDB [test]> explain select (select 2); +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ \| id \| select_type \| table \| type \| possible_keys \| key \| key_len \| ref \| rows \| Extra \| +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ \| 1 \| SIMPLE \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| No tables used \| +------+-------------+-------+------+---------------+------+---------+------+------+----------------+ 1 row in set, 1 warning (0,000 sec) In case the statement CREATE TABLE t1 SELECT * FROM (SELECT 1 AS a, (SELECT a+0)) a is run in PS mode it fails with the error ERROR 1054 (42S22): Unknown column 'a' in 'field list'. - Uniform handling of read-only variables both in case the SET var=val statement is executed as regular or prepared statememt. - Fixed assertion firing on handling LOAD DATA statement for temporary tables - Relaxed assert condition in the function lex_end_stage1() by adding the commands SQLCOM_ALTER_EVENT, SQLCOM_CREATE_PACKAGE, SQLCOM_CREATE_PACKAGE_BODY to a list of supported command - Removed raising of the error ER_UNSUPPORTED_PS in the function check_prepared_statement() for the ALTER VIEW command - Added initialization of the data memember st_select_lex_unit::last_procedure (assign NULL value) in the constructor Without this change the test case main.ctype_utf8 fails with the following report in case it is run with the optoin --ps-protocol. mysqltest: At line 2278: query 'VALUES (_latin1 0xDF) UNION VALUES(_utf8'a' COLLATE utf8_bin)' failed: 2013: Lost connection - The following bug reports were fixed: MDEV-24460: Multiple rows result set returned from stored routine over prepared statement binary protocol is handled incorrectly CONC-519: mariadb client library doesn't handle server_status and warnign_count fields received in the packet COM_STMT_EXECUTE_RESPONSE. Reasons for these bug reports have the same nature and caused by missing loop iteration on results sent by server in response to COM_STMT_EXECUTE packet. Enclosing of statements for processing of COM_STMT_EXECUTE response in the construct like do { ... } while (!mysql_stmt_next_result()); fixes the above mentioned bug reports.	5 years ago
Sergei Golubchik	3648b333c7	cleanup: formatting also avoid an oxymoron of using `MYSQL_PLUGIN_IMPORT` under `#ifdef MYSQL_SERVER`, and empty_clex_str is so trivial that a plugin can define it if needed.	4 years ago
Sergei Golubchik	4777097fee	followup: rename generated files to have distinct names	4 years ago
Sergei Golubchik	dfbeddaa11	MDEV-25726 get rid of cmake comment hack in sql_yacc.yy and replace it with equally unsightly %ifdef/%endif hack also, support %else, it's nice	4 years ago
Igor Babaev	675716e1cb	MDEV-23886 Reusing CTE inside a function fails with table doesn't exist In the code existed just before this patch binding of a table reference to the specification of the corresponding CTE happens in the function open_and_process_table(). If the table reference is not the first in the query the specification is cloned in the same way as the specification of a view is cloned for any reference of the view. This works fine for standalone queries, but does not work for stored procedures / functions for the following reason. When the first call of a stored procedure/ function SP is processed the body of SP is parsed. When a query of SP is parsed the info on each encountered table reference is put into a TABLE_LIST object linked into a global chain associated with the query. When parsing of the query is finished the basic info on the table references from this chain except table references to derived tables and information schema tables is put in one hash table associated with SP. When parsing of the body of SP is finished this hash table is used to construct TABLE_LIST objects for all table references mentioned in SP and link them into the list of such objects passed to a pre-locking process that calls open_and_process_table() for each table from the list. When a TABLE_LIST for a view is encountered the view is opened and its specification is parsed. For any table reference occurred in the specification a new TABLE_LIST object is created to be included into the list for pre-locking. After all objects in the pre-locking have been looked through the tables mentioned in the list are locked. Note that the objects referenced CTEs are just skipped here as it is impossible to resolve these references without any info on the context where they occur. Now the statements from the body of SP are executed one by one that. At the very beginning of the execution of a query the tables used in the query are opened and open_and_process_table() now is called for each table reference mentioned in the list of TABLE_LIST objects associated with the query that was built when the query was parsed. For each table reference first the reference is checked against CTEs definitions in whose scope it occurred. If such definition is found the reference is considered resolved and if this is not the first reference to the found CTE the the specification of the CTE is re-parsed and the result of the parsing is added to the parsing tree of the query as a sub-tree. If this sub-tree contains table references to other tables they are added to the list of TABLE_LIST objects associated with the query in order the referenced tables to be opened. When the procedure that opens the tables comes to the TABLE_LIST object created for a non-first reference to a CTE it discovers that the referenced table instance is not locked and reports an error. Thus processing non-first table references to a CTE similar to how references to view are processed does not work for queries used in stored procedures / functions. And the main problem is that the current pre-locking mechanism employed for stored procedures / functions does not allow to save the context in which a CTE reference occur. It's not trivial to save the info about the context where a CTE reference occurs while the resolution of the table reference cannot be done without this context and consequentially the specification for the table reference cannot be determined. This patch solves the above problem by moving resolution of all CTE references at the parsing stage. More exactly references to CTEs occurred in a query are resolved right after parsing of the query has finished. After resolution any CTE reference it is marked as a reference to to derived table. So it is excluded from the hash table created for pre-locking used base tables and view when the first call of a stored procedure / function is processed. This solution required recursive calls of the parser. The function THD::sql_parser() has been added specifically for recursive invocations of the parser. # Conflicts: # sql/sql_cte.cc # sql/sql_cte.h # sql/sql_lex.cc # sql/sql_lex.h # sql/sql_view.cc # sql/sql_yacc.yy # sql/sql_yacc_ora.yy	4 years ago

1 2 3 4 5 ...

2721 Commits (19644f6821d59ecca0f9b1f44fadb3b887061965)