mariadb

Commit Graph

Author	SHA1	Message	Date
Sergei Golubchik	a69da0c31e	MDEV-19761 Before Trigger not processed for Not Null Columns if no explicit value and no DEFAULT it's incorrect to zero out table->triggers->extra_null_bitmap before a statement, because if insert uses an explicit field list and omits a field that has no default value, the field should get NULL implicitly. So extra_null_bitmap should have 1s for all fields that have no defaults * create extra_null_bitmap_init and initialize it as above * copy extra_null_bitmap_init to extra_null_bitmap for inserts * still zero out extra_null_bitmap for updates/deletes where all fields definitely have a value * make not_null_fields_have_null_values() to send ER_NO_DEFAULT_FOR_FIELD for fields with no default and no value, otherwise creation of a trigger with an empty body would change the error message	10 months ago
Oleksandr Byelkin	0d35fe6e57	MDEV-35326: Memory Leak in init_io_cache_ext upon SHUTDOWN The problems were that: 1) resources was freed "asimetric" normal execution in send_eof, in case of error in destructor. 2) destructor was not called in case of SP for result objects. (so if the last SP execution ended with error resorces was not freeded on reinit before execution (cleanup() called before next execution) and destructor also was not called due to lack of delete call for the object) Result cleanup() renamed to reset_for_next_ps_execution() to better reflect function(). All result method revised and freeing resources made "symetric". Destructor of result object called for SP. Added skipped invalidation in case of error in insert. Removed misleading naming of reset(thd) (could be mixed with with reset()).	10 months ago
Dmitry Shulga	54c1031b74	MDEV-34958: after Trigger doesn't work correctly with bulk insert This bug has the same nature as the issues MDEV-34718: Trigger doesn't work correctly with bulk update MDEV-24411: Trigger doesn't work correctly with bulk insert To fix the issue covering all use cases, resetting the thd->bulk_param temporary to the value nullptr before invoking triggers and restoring its original value on finishing execution of a trigger is moved to the method Table_triggers_list::process_triggers that be invoked ultimately for any kind of triggers.	10 months ago
Brandon Nesterenko	dbfee9fc2b	MDEV-34348: Consolidate cmp function declarations Partial commit of the greater MDEV-34348 scope. MDEV-34348: MariaDB is violating clang-16 -Wcast-function-type-strict The functions queue_compare, qsort2_cmp, and qsort_cmp2 all had similar interfaces, and were used interchangable and unsafely cast to one another. This patch consolidates the functions all into the qsort_cmp2 interface. Reviewed By: ============ Marko Mäkelä <marko.makela@mariadb.com>	12 months ago
Yuchen Pei	b8c2bd9f69	MDEV-35249 Fix regression caused by MDEV-34447 MDEV-34447 Removed setting first_cond_optimization to 0 in update and delete when leaf_tables_saved. This can cause problems when two ps executions of an update go through different paths, where the first ps execution goes through single table update only and the second ps execution also goes through multi table update. When this happens, the first_cond_optimization of the outer query is not set to false during the first ps execution because optimize() is not called for the outer query. But then the second ps execution will call optimize() on the outer query, which with first_cond_optimization==true trips the 2nd ps mem leak detection. This is not a problem in higher version as both executions go through multi table updates, possibly due to MDEV-28883. We fix this problem by restoring the FALSE assignments to first_cond_optimization.	12 months ago
Yuchen Pei	e886c2ba02	MDEV-34757 Check leaf_tables_saved in partition pruning in UPDATE and DELETE	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
Dmitry Shulga	ba5482ffc2	MDEV-34718: Trigger doesn't work correctly with bulk update Running an UPDATE statement in PS mode and having positional parameter(s) bound with an array of actual values (that is prepared to be run in bulk mode) results in incorrect behaviour in presence of on update trigger that also executes an UPDATE statement. The same is true for handling a DELETE statement in presence of on delete trigger. Typically, the visible effect of such incorrect behaviour is expressed in a wrong number of updated/deleted rows of a target table. Additionally, in case UPDATE statement, a number of modified rows and a state message returned by a statement contains wrong information about a number of modified rows. The reason for incorrect number of updated/deleted rows is that a data structure used for binding positional argument with its actual values is stored in THD (this is thd->bulk_param) and reused on processing every INSERT/UPDATE/DELETE statement. It leads to consuming actual values bound with top-level UPDATE/DELETE statement by other DML statements used by triggers' body. To fix the issue, reset the thd->bulk_param temporary to the value nullptr before invoking triggers and restore its value on finishing its execution. The second part of the problem relating with wrong value of affected rows reported by Connector/C API is caused by the fact that diagnostics area is reused by an original DML statement and a statement invoked by a trigger. This fact should be take into account on finalizing a state of diagnostics area on completion running of a statement. Important remark: in case the macros DBUG_OFF is on, call of the method Diagnostics_area::reset_diagnostics_area() results in reset of the data members m_affected_rows, m_statement_warn_count. Values of these data members of the class Diagnostics_area are used on sending OK and EOF messages. In case DML statement is executed in PS bulk mode such resetting results in sending wrong result values to a client for affected rows in case the DML statement fires a triggers. So, reset these data members only in case the current statement being processed is not run in bulk mode.	1 year ago
Nikita Malyavin	68c1fbfc17	MDEV-25370 Update for portion changes autoincrement key in bi-temp table According to the standard, the autoincrement column (i.e. identity column) should be advanced each insert implicitly made by UPDATE/DELETE ... FOR PORTION. This is very unconvenient use in several notable cases. Concider a WITHOUT OVERLAPS key with an autoinc column: id int auto_increment, unique(id, p without overlaps) An update or delete with FOR PORTION creates a sense that id will remain unchanged in such case. The standard's IDENTITY reminds MariaDB's AUTO_INCREMENT, however the generation rules differ in many ways. For example, there's also a notion autoincrement index, which is bound to the autoincrement field. We will define our own generation rule for the PORTION OF operations involving AUTO_INCREMENT: * If an autoincrement index contains WITHOUT OVERLAPS specification, then a new value should not be generated, otherwise it should. Apart from WITHOUT OVERLAPS there is also another notable case, referred by the reporter - a unique key that has an autoincrement column and a field from the period specification: id int auto_increment, unique(id, s), period for p(s, e) for this case, no exception is made, and the autoincrementing rules will be proceeded accordung to the standard (i.e. the value will be advanced on implicit inserts).	2 years ago
Rex	c6a9fd7904	MDEV-32212 DELETE with ORDER BY and semijoin optimization causing crash Statements affected by this bug are delete statements that have all these conditions 1) single table delete syntax 2) and in (sub-query) predicate 3) semi-join optimization enabled 4) an order by clause. Semijoin optimization on an innocent looking query, such as DELETE FROM t1 WHERE c1 IN (select c2 from t2) ORDER BY c1; turns it from a single table delete to a multi-table delete. During multi_delete::initialize_tables for the top level join object, a table is initialized missing a keep_current_rowid flag, needed to position a handler for removal of the correct row after the filesort structure has been built. Fix provided by Monty (monty@mariadb.com) Pushed into 10.5 at Monty's request. Applicable to 10.6, 10.11, 11.0. OK'd by Monty in slack:#askmonty 2023-12-01	2 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
Jan Lindström	4eb8e51c26	Merge 10.4 into 10.5	3 years ago
lrf141	da03d8d99f	MDEV-19190 Assertion `...auto_inc_initialized` failed in get_auto_increment This is a DELETE only case. Normally this statement doesn't make inserts, but DELETE ... FOR PORTION changes it. UPDATE and INSERT initializes autoinc by calling handler::info(HA_STATUS_AUTO). Also myisam and innodb can lazily initialize it in their update_create_info overrides. The solution is to initialize autoinc during delete preparation, if period (DELETE FOR PORTION) is specified. The initial work has been done by Kento Takeuchi by his PR #2048, however this commit also holds a few technical modifications by Nikita Malyavin	4 years ago
Thirunarayanan Balathandayuthapani	f9ec9b6abb	MDEV-27282 InnoDB: Failing assertion: !query->intersection - query->intersection fails to get freed if the query exceeds innodb_ft_result_cache_limit - errors from init_ftfuncs were not propogated by delete command This is taken from percona/percona-server@ef2c0bcb9a34aeb06de0058d7c2a2969416b35a7	3 years ago
Sergei Golubchik	6789f2cfab	MDEV-18304 sql_safe_updates does not work with OR clauses not every index-using plan sets bits in table->quick_keys. QUICK_ROR_INTERSECT_SELECT, for example, doesn't. Use the fact that select->quick is set instead. Also allow EXPLAIN to work.	4 years ago
Daniel Ye	9fc1ef932f	MDEV-26545 Spider does not correctly handle UDF and stored function in where conds - Handle stored function conditions correctly, with the same logic as with UDFs. - When running queries on Spider SE, by default, we do not push down WHERE conditions containing usage of UDFs/stored functions to remote data nodes, unless the user demands (by setting spider_use_pushdown_udf). - Disable direct update/delete when a udf condition is skipped.	4 years ago
Oleksandr Byelkin	a7d880f0b0	MDEV-21916: COM_STMT_BULK_EXECUTE with RETURNING insert wrong values The problem is that array binding uses net buffer to read parameters for each execution while each execiting with RETURNING write in the same buffer. Solution is to allocate new net buffer to avoid changing buffer we are reading from.	5 years ago
Dmitry Shulga	91bde0fb67	MDEV-25576: The statement EXPLAIN running as regular statement and as prepared statement produces different results for UPDATE with subquery Both EXPLAIN and EXPLAIN EXTENDED statements produce different results set in case it is run in normal way and in PS mode for the statements UPDATE/DELETE with subquery. The use case below reproduces the issue: MariaDB [test]> CREATE TABLE t1 (c1 INT KEY) ENGINE=MyISAM; Query OK, 0 rows affected (0,128 sec) MariaDB [test]> CREATE TABLE t2 (c2 INT) ENGINE=MyISAM; Query OK, 0 rows affected (0,023 sec) MariaDB [test]> CREATE TABLE t3 (c3 INT) ENGINE=MyISAM; Query OK, 0 rows affected (0,021 sec) MariaDB [test]> EXPLAIN EXTENDED UPDATE t3 SET c3 = -> ( SELECT COUNT(d1.c1) FROM ( SELECT a11.c1 FROM t1 AS a11 -> STRAIGHT_JOIN t2 AS a21 ON a21.c2 = a11.c1 JOIN t1 AS a12 -> ON a12.c1 = a11.c1 ) d1 ); +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ \| id \| select_type \| table \| type \| possible_keys \| key \| key_len \| ref \| rows \| filtered \| Extra \| +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ \| 1 \| PRIMARY \| t3 \| ALL \| NULL \| NULL \| NULL \| NULL \| 0 \| 100.00 \| \| \| 2 \| SUBQUERY \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| Impossible WHERE noticed after reading const tables +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ 2 rows in set (0,002 sec) MariaDB [test]> PREPARE stmt FROM -> EXPLAIN EXTENDED UPDATE t3 SET c3 = -> ( SELECT COUNT(d1.c1) FROM ( SELECT a11.c1 FROM t1 AS a11 -> STRAIGHT_JOIN t2 AS a21 ON a21.c2 = a11.c1 JOIN t1 AS a12 -> ON a12.c1 = a11.c1 ) d1 ); 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 \| filtered \| Extra \| +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ \| 1 \| PRIMARY \| t3 \| ALL \| NULL \| NULL \| NULL \| NULL \| 0 \| 100.00 \| \| \| 2 \| SUBQUERY \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| NULL \| no matching row in const table \| +------+-------------+-------+------+---------------+------+---------+------+------+----------+--------------------------------+ 2 rows in set (0,000 sec) The reason by that different result sets are produced is that on execution of the statement 'EXECUTE stmt' the flag SELECT_DESCRIBE not set in the data member SELECT_LEX::options for instances of SELECT_LEX that correspond to subqueries used in the UPDTAE/DELETE statements. Initially, these flags were set on parsing the statement PREPARE stmt FROM "EXPLAIN EXTENDED UPDATE t3 SET ..." but latter they were reset before starting real execution of the parsed query during handling the statement 'EXECUTE stmt'; So, to fix the issue the functions mysql_update()/mysql_delete() have been modified to set the flag SELECT_DESCRIBE forcibly in the data member SELECT_LEX::options for the primary SELECT_LEX of the UPDATE/DELETE statement.	4 years ago
Igor Babaev	2c9bf0ae87	This commit adds the same call of st_select_lex::set_unique_exclude() that complemented the fix for MDEV-24823 in 10.2. As it is the only call of this function in 10.3 the commit also has added the code of the function.	5 years ago
Igor Babaev	1288dfffe7	This patch complements the patch for MDEV-24823.	5 years ago
Igor Babaev	e3a25793be	MDEV-24823 Crash with invalid multi-table update of view in 2nd execution of SP Before this patch mergeable derived tables / view used in a multi-table update / delete were merged before the preparation stage. When the merge of a derived table / view is performed the on expression attached to it is fixed and ANDed with the where condition of the select S containing this derived table / view. It happens after the specification of the derived table / view has been merged into S. If the ON expression refers to a non existing field an error is reported and some other mergeable derived tables / views remain unmerged. It's not a problem if the multi-table update / delete statement is standalone. Yet if it is used in a stored procedure the select with incompletely merged derived tables / views may cause a problem for the second call of the procedure. This does not happen for select queries using derived tables / views, because in this case their specifications are merged after the preparation stage at which all ON expressions are fixed. This patch makes sure that merging of the derived tables / views used in a multi-table update / delete statement is performed after the preparation stage. Approved by Oleksandr Byelkin <sanja@mariadb.com>	5 years ago
Igor Babaev	b3b5d57e78	MDEV-24823 Crash with invalid multi-table update of view in 2nd execution of SP Before this patch mergeable derived tables / view used in a multi-table update / delete were merged before the preparation stage. When the merge of a derived table / view is performed the on expression attached to it is fixed and ANDed with the where condition of the select S containing this derived table / view. It happens after the specification of the derived table / view has been merged into S. If the ON expression refers to a non existing field an error is reported and some other mergeable derived tables / views remain unmerged. It's not a problem if the multi-table update / delete statement is standalone. Yet if it is used in a stored procedure the select with incompletely merged derived tables / views may cause a problem for the second call of the procedure. This does not happen for select queries using derived tables / views, because in this case their specifications are merged after the preparation stage at which all ON expressions are fixed. This patch makes sure that merging of the derived tables / views used in a multi-table update / delete statement is performed after the preparation stage. Approved by Oleksandr Byelkin <sanja@mariadb.com>	5 years ago
Aleksey Midenkov	932ec586aa	MDEV-23644 Assertion on evaluating foreign referential action for self-reference in system versioned table First part of the fix (row0mysql.cc) addresses external columns when adding history row on referential action. The full data must be retrieved before the row is inserted. Second part of the fix (the rest) avoids duplicate primary key error between the history row generated on referential action and the history row generated by SQL command. Both command and referential action can happen on same table since foreign key can be self-reference (parent and child tables are same). Moreover, the self-reference can refer multiple rows when the key is non-unique. In such case history is generated by referential action occured on first row but processed all rows by a matched key. The second round is when the next row is processed by a command but history already exists. In such case we check TRX_ID of existing history row and if it is the same we assume the above situation and skip adding one more history row or failing the command.	5 years ago
Nikita Malyavin	5896a49820	MDEV-19130 Assertion failed in handler::update_auto_increment add store/restore_auto_increment in period portion insert/update functions	6 years ago
Monty	6cee9b1953	MDEV-22535 TABLE::initialize_quick_structures() takes 0.5% in oltp_read_only Fixed by: - Make all quick_* variable allocated according to real number keys instead of MAX_KEY - Store all the quick* items in separated allocated structure (OPT_RANGE) - Ensure we don't access any quick* variable without first checking opt_range_keys.is_set(). Thanks to this, we don't need any pre-initialization of quick* variables anymore. Some renames was done to use the new structure: table->quick_keys -> table->opt_range_keys table->quick_rows[X] -> table->opt_range[X].rows table->quick_key_parts[X] -> table->opt_range[X].key_parts table->quick_costs[X] -> table->opt_range[X].cost table->quick_index_only_costs[X] -> table->opt_range[X].index_only_cost table->quick_n_ranges[X] -> table->opt_range[X].ranges table->quick_condition_rows -> table->opt_range_condition_rows This patch should both decrease memory needed for TABLE objects (3528 -> 984 + keyinfo) and increase performance, thanks to less initializations per query, and more localized memory, thanks to the opt_range structure.	5 years ago
Monty	4102f1589c	Aria will now register it's transactions MDEV-22531 Remove maria::implicit_commit() MDEV-22607 Assertion `ha_info->ht() != binlog_hton' failed in MYSQL_BIN_LOG::unlog_xa_prepare From the handler point of view, Aria now looks like a transactional engine. One effect of this is that we don't need to call maria::implicit_commit() anymore. This change also forces the server to call trans_commit_stmt() after doing any read or writes to system tables. This work will also make it easier to later allow users to have system tables in other engines than Aria. To handle the case that Aria doesn't support rollback, a new handlerton flag, HTON_NO_ROLLBACK, was added to engines that has transactions without rollback (for the moment only binlog and Aria). Other things - Moved freeing of MARIA_SHARE to a separate function as the MARIA_SHARE can be still part of a transaction even if the table has closed. - Changed Aria checkpoint to use the new MARIA_SHARE free function. This fixes a possible memory leak when using S3 tables - Changed testing of binlog_hton to instead test for HTON_NO_ROLLBACK - Removed checking of has_transaction_manager() in handler.cc as we can assume that as the transaction was started by the engine, it does support transactions. - Added new class 'start_new_trans' that can be used to start indepdendent sub transactions, for example while reading mysql.proc, using help or status tables etc. - open_system_tables...() and open_proc_table_for_Read() doesn't anymore take a Open_tables_backup list. This is now handled by 'start_new_trans'. - Split thd::has_transactions() to thd::has_transactions() and thd::has_transactions_and_rollback() - Added handlerton code to free cached transactions objects. Needed by InnoDB. squash! `2ed35999f2`	6 years ago
Monty	d1d472646d	Change THD->transaction to a pointer to enable multiple transactions All changes (except one) is of type thd->transaction. -> thd->transaction-> thd->transaction points by default to 'thd->default_transaction' This allows us to 'easily' have multiple active transactions for a THD object, like when reading data from the mysql.proc table	6 years ago
Sergei Golubchik	937dfb74cb	MDEV-22424 Server crashes in handler::check_duplicate_long_entry_key or Assertion `inited == NONE \|\| lookup_handler != this' failed upon DELETE FOR PORTION on table with long unique key even if we're allowed to convert DELETE .. FOR PERIOD OF into an update internally, doesn't think we'll be able to. We always have to prepare for insert.	6 years ago
Monty	e3130d22e1	Fixed some assert crashes related to keyread. - MDEV-22062 Assertion `!table->file->keyread_enabled()' failed in close_thread_table() - MDEV-22077 table->no_keyread .. failed in join_read_first() - MDEV-22237 Assertion `!table->file->keyread_enabled()' failed in handler::ha_reset on DELETE	6 years ago
Sergei Golubchik	fcd84da5f1	MDEV-22218 InnoDB: Failing assertion: node->pcur->rel_pos == BTR_PCUR_ON upon LOAD DATA with NO_BACKSLASH_ESCAPES in SQL_MODE and unique blob in table `inited == NONE` at the initialization time does not always mean that it'll be `NONE` later, at the execution time. Use a more complex caller-specific logic to decide whether to create a cloned lookup handler. Besides LOAD (as in the original bug report) make sure that all prepare_for_insert() invocations are covered by tests. Add tests for CREATE ... SELECT, multi-UPDATE, and multi-DELETE. Don't enable write cache with long uniques.	6 years ago
Sergei Golubchik	0515577d12	cleanup: prepare "update_handler" for WITHOUT OVERLAPS * rename to a generic name * move remaning initializations from query exec to prepare time * simplify/unify key handling in open_table_from_share and delayed * remove dead code * move tests where they belong	6 years ago
Monty	4ef437558a	Improve update handler (long unique keys on blobs) MDEV-21606 Improve update handler (long unique keys on blobs) MDEV-21470 MyISAM and Aria start_bulk_insert doesn't work with long unique MDEV-21606 Bug fix for previous version of this code MDEV-21819 2 Assertion `inited == NONE \|\| update_handler != this' - Move update_handler from TABLE to handler - Move out initialization of update handler from ha_write_row() to prepare_for_insert() - Fixed that INSERT DELAYED works with update handler - Give an error if using long unique with an autoincrement column - Added handler function to check if table has long unique hash indexes - Disable write cache in MyISAM and Aria when using update_handler as if cache is used, the row will not be inserted until end of statement and update_handler would not find conflicting rows. - Removed not used handler argument from check_duplicate_long_entries_update() - Syntax cleanups - Indentation fixes - Don't use single character indentifiers for arguments	6 years ago
Alexander Barkov	a1e330de5a	MDEV-21743 Split up SUPER privilege to smaller privileges	6 years ago
Aleksey Midenkov	cef2b34f25	MDEV-18929 2nd execution of SP does not detect ER_VERS_NOT_VERSIONED Wrong assertion condition. SYSTEM_TIME_ALL indicates that vers_setup_conds() is done. In case FOR SYSTEM_TIME ALL is specified in command the assertion passes but not checks anything.	6 years ago
Aleksey Midenkov	33f55789d3	MDEV-18727 improve DML operation of System Versioning (10.4) UPDATE, DELETE: replace linear search of current/historical records with vers_setup_conds(). Additional DML cases in view.test	6 years ago
Aleksey Midenkov	bf58ec77a1	MDEV-18727 cleanup	6 years ago
Aleksey Midenkov	0076dce2c8	MDEV-18727 improve DML operation of System Versioning MDEV-18957 UPDATE with LIMIT clause is wrong for versioned partitioned tables UPDATE, DELETE: replace linear search of current/historical records with vers_setup_conds(). Additional DML cases in view.test	6 years ago
Sergei Petrunia	68ed3a81f2	MDEV-20854: ANALYZE for statements: not clear where the time is spent Count the "gap" time between table accesses and display it as r_other_time_ms in the "table" element. * The advantage of this approach is that it doesn't add any new my_timer_cycles() calls. * The disadvantage is that the definition of what is done during "other time" is not that clear: it includes checking the WHERE (for this table), constructing index lookup tuple (for the next table) writing to GROUP BY temporary table (as we dont account for that time separately [yet], etc)	6 years ago
Monty	b62101f84b	Fixes for binary logging --read-only mode - Any temporary tables created under read-only mode will never be logged to binary log. Any usage of these tables to update normal tables, even after read-only has been disabled, will use row base logging (as the temporary table will not be on the slave). - Analyze, check and repair table will not be logged in read-only mode. Other things: - Removed not used varaibles in MYSQL_BIN_LOG::flush_and_set_pending_rows_event. - Set table_share->table_creation_was_logged for all normal tables. - THD::binlog_query() now returns -1 if statement was not logged., This is used to update table_share->table_creation_was_logged. - Don't log admin statements in opt_readonly is set. - Table's that doesn't have table_creation_was_logged will set binlog format to row logging. - Removed not needed/wrong setting of table->s->table_creation_was_logged in create_table_from_items()	6 years ago
Rucha Deodhar	837ad9ab97	MDEV-10014 Add RETURNING to INSERT Closes #1384	6 years ago
Sergei Golubchik	57a09a72a3	cleanup st_select_lex_unit::explainable	6 years ago
Sergei Golubchik	721a9df751	cleanup: formatting comments, whitespaces	6 years ago
Sergei Golubchik	a4a025f5d1	cleanup: don't pass wild_num to setup_wild() because internally setup_wild() adjusts select_lex->with_wild directly anyway, so there is no reason to pretend that the number of '*' may be anything else but select_lex->with_wild And don't update select_lex->item_list, because fields can come from anywhere and don't necessarily have to be copied into select_lex.	6 years ago
Oleksandr Byelkin	1ae02f0e0d	MDEV-18553: MDEV-16327 pre-requisits part 2: uniform of LIMIT/OFFSET handling Now both offset and limit are stored and do not chenged during execution (offset is decreased during processing in versions before 10.5). (Big part of this changes made by Monty)	6 years ago
Aleksey Midenkov	f6d0d309fa	MDEV-19814 Assertion `update->n_fields < ulint(table->n_cols + table->n_v_cols)' on DELETE HISTORY Turn off versioned_write for DELETE HISTORY.	6 years ago
Aleksey Midenkov	1a73444d57	Cleanups: DELETE HISTORY [MDEV-19814] * Made make_versioned_() proxies inline; Renamed truncate_history to delete_history Part of: MDEV-19814 Server crash in row_upd_del_mark_clust_rec or Assertion `update->n_fields < ulint(table->n_cols + table->n_v_cols)' failed in upd_node_t::make_versioned_helper	6 years ago
Nisha Gopalakrishnan	2536c0b1eb	BUG#28642318: POINT IN TIME RECOVERY USING MYSQLBINLOG BROKEN WITH TEMPORARY TABLE -> ERRORS Analysis ======== Point in time recovery using mysqlbinlog containing queries operating on temporary tables results in an error. While writing the query log event in the binary log, the thread id used for execution of DROP TABLE and DELETE commands were incorrect. The thread variable 'thread_specific_used' is used to determine whether a specific thread id is to used while executing the statements i.e using 'SET @@session.pseudo_thread_id'. This variable was not set correctly for DROP TABLE query and was never set for DELETE query. The thread id is important for temporary tables since the tables are session specific. DROP TABLE and DELETE queries executed using a wrong thread id resulted in errors while applying the queries generated by mysqlbinlog utility. Fix === Set the 'thread_specific_used' THD variable for DROP TABLE and DELETE queries. ReviewBoard: 21833	7 years ago
Sergei Golubchik	43623f04a9	MDEV-15458 Segfault in heap_scan() upon UPDATE after ADD SYSTEM VERSIONING handler::write_row() should not destroy the state of the running index_search/index_next/... or rnd_init/rnd_next/... scan	7 years ago
Vicențiu Ciorbaru	5543b75550	Update FSF Address * Update wrong zip-code	7 years ago
Nikita Malyavin	7e3e2d060b	MDEV-18859 Server crashes in bitmap_bits_set / pack_row / THD::binlog_write_row upon DELETE .. FOR PORTION with binary logging rpl_write_set is initialized in TABLE::mark_columns_per_binlog_row_image. Since we just call use_all_columns for PORTION OF case, no need in column marking logic here. Instead, initialize table->rpl_write_set in place.	7 years ago

1 2 3 4 5 ...

924 Commits (a69da0c31e97109bba099022acdd393f92fa127f)