summaryrefslogtreecommitdiff
path: root/sql/sql_class.cc
Commit message (Collapse)AuthorAgeFilesLines
* fix assertionNikita Malyavin2020-07-221-1/+0
|
* fix c++98 buildNikita Malyavin2020-07-211-2/+2
|
* MDEV-16039 Crash when selecting virtual columns generated using functions ↵Nikita Malyavin2020-07-211-2/+2
| | | | | | | | | | | | | | with DAYNAME() * Allocate items on thd->mem_root while refixing vcol exprs * Make vcol tree changes register and roll them back after the statement is executed. Explanation: Due to collation implementation specifics an Item tree could change while fixing. The tricky thing here is to make it on a proper arena. It's usually not a problem when a field is deterministic, however, makes a pain vice-versa, during allocation allocating. A non-deterministic field should be refixed on each statement, since it depends on the environment state. Changing the tree will be temporary and therefore it should be reverted after the statement execution.
* MDEV-22529 thd_query_safe() isn’t, causing InnoDB to hangMarko Mäkelä2020-05-121-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function thd_query_safe() is used in the implementation of the following INFORMATION_SCHEMA views: information_schema.innodb_trx information_schema.innodb_locks information_schema.innodb_lock_waits information_schema.rocksdb_trx The implementation of the InnoDB views is in trx_i_s_common_fill_table(). This function invokes trx_i_s_possibly_fetch_data_into_cache(), which will acquire lock_sys->mutex and trx_sys->mutex in order to protect the set of active transactions and explicit locks. While holding those mutexes, it will traverse the collection of InnoDB transactions. For each transaction, thd_query_safe() will be invoked. When called via trx_i_s_common_fill_table(), thd_query_safe() is acquiring THD::LOCK_thd_data while holding the InnoDB locks. This will cause a deadlock with THD::awake() (such as executing KILL QUERY), because THD::awake() could invoke lock_trx_handle_wait(), which attempts to acquire lock_sys->mutex while already holding THD::lock_thd_data. thd_query_safe(): Invoke mysql_mutex_trylock() instead of mysql_mutex_lock(). Return the empty string if the mutex cannot be acquired without waiting.
* Merge branch '10.1' into 10.2Oleksandr Byelkin2020-05-021-0/+5
|\
| * Merge branch '5.5' into 10.1Oleksandr Byelkin2020-04-301-0/+2
| |\
| | * Bug#29915479 RUNNING COM_REGISTER_SLAVE WITHOUT COM_BINLOG_DUMP CAN RESULTS ↵Sergei Golubchik2020-04-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IN SERVER EXIT in fact, in MariaDB it cannot, but it can show spurious slaves in SHOW SLAVE HOSTS. slave was registered in COM_REGISTER_SLAVE and un-registered after COM_BINLOG_DUMP. If there was no COM_BINLOG_DUMP, it would never unregister.
* | | MDEV-21473 conflicts with async slave BF aborting (#1475)seppo2020-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | If async slave thread (slave SQL handler), becomes a BF victim, it may occasionally happen that rollbacker thread is used to carry out the rollback instead of the async slave thread. This can happen, if async slave thread has flagged "idle" state when BF thread tries to figure out how to kill the victim. The issue was possible to test by using a galera cluster as slave for external master, and issuing high load of conflicting writes through async replication and directly against galera cluster nodes. However, a deterministic mtr test for the "conflict window" has not yet been worked on. The fix, in this patch makes sure that async slave thread state is never set to IDLE. This prevents the rollbacker thread to intervene. The wsrep_query_state change was refactored to happen by dedicated function to make controlling the idle state change in one place.
* | | MDEV-19658 UBSAN: runtime error: load of value 2779096485, which is not a ↵Eugene Kosov2020-03-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | valid value for type 'enum_binlog_format' This is an uninitialized read. THD::THD: initialize current_stmt_binlog_format member
* | | Fix GCC 10 -Wclass-memaccessMarko Mäkelä2020-03-131-1/+1
| | |
* | | Merge 10.1 into 10.2Marko Mäkelä2019-10-091-1/+0
|\ \ \ | |/ /
| * | MDEV-19536 - Server crash or ASAN heap-use-after-free in is_temporary_table /Sergey Vojtovich2019-10-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | read_statistics_for_tables_if_needed Regression after 279a907, read_statistics_for_tables_if_needed() was called after open_normal_and_derived_tables() failure. Fixed by moving read_statistics_for_tables() call to a branch of get_schema_stat_record() where result of open_normal_and_derived_tables() is checked. Removed THD::force_read_stats, added read_statistics_for_tables() instead. Simplified away statistics_for_command_is_needed().
* | | MDEV-17614: After-merge fixMarko Mäkelä2019-08-121-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-17614 flags INSERT…ON DUPLICATE KEY UPDATE unsafe for statement-based replication when there are multiple unique indexes. This correctly fixes something whose attempted fix in MySQL 5.7 in mysql/mysql-server@c93b0d9a972cb6f98fd445f2b69d924350f9128a caused lock conflicts. That change was reverted in MySQL 5.7.26 in mysql/mysql-server@066b6fdd433aa6673622341f1a2f0a3a20018043 (with a substantial amount of other changes). In MDEV-17073 we already disabled the unfortunate MySQL change when statement-based replication was not being used. Now, thanks to MDEV-17614, we can actually remove the change altogether. This reverts commit 8a346f31b913daa011085afec2b2d38450c73e00 (MDEV-17073) and mysql/mysql-server@c93b0d9a972cb6f98fd445f2b69d924350f9128a while keeping the test cases.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-08-121-0/+42
|\ \ \ | |/ /
| * | MDEV-17614 INSERT on dup key update is replication unsafeSachin2019-08-091-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem:- When mysql executes INSERT ON DUPLICATE KEY INSERT, the storage engine checks if the inserted row would generate a duplicate key error. If yes, it returns the existing row to mysql, mysql updates it and sends it back to the storage engine.When the table has more than one unique or primary key, this statement is sensitive to the order in which the storage engines checks the keys. Depending on this order, the storage engine may determine different rows to mysql, and hence mysql can update different rows.The order that the storage engine checks keys is not deterministic. For example, InnoDB checks keys in an order that depends on the order in which indexes were added to the table. The first added index is checked first. So if master and slave have added indexes in different orders, then slave may go out of sync. Solution:- Make INSERT...ON DUPLICATE KEY UPDATE unsafe while using stmt or mixed format When there is more then one unique key. Although there is two exception. 1. Auto Increment key is not counted because Innodb will get gap lock for failed Insert and concurrent insert will get a next increment value. But if user supplies auto inc value it can be unsafe. 2. Count only unique keys for which insertion is performed. So this patch also addresses the bug id #72921
* | | MDEV-16222 Assertion `0' failed in row_purge_remove_sec_if_poss_leaf on ↵Aleksey Midenkov2019-07-081-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | table with virtual columns and indexes Cause Stale thd->m_stmt_da->m_sql_errno which is from different invocation. Fix Reset error state before attempt to open table.
* | | Merge 10.1 into 10.2Eugene Kosov2019-06-231-0/+3
|\ \ \ | |/ /
| * | MDEV-18661 loading the audit plugin causes performance regression.Alexey Botchkov2019-06-151-1/+3
| | | | | | | | | | | | | | | | | | Plugin fixed to not lock the LOCK_operations when not active. Server fixed to lock the LOCK_plugin less - do it once per thread and then only if a plugin was installed/uninstalled.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-1/+1
|\ \ \ | |/ /
| * | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| |\ \ | | |/
| | * Update FSF AddressVicențiu Ciorbaru2019-05-111-1/+1
| | | | | | | | | | | | * Update wrong zip-code
* | | Merge branch '10.1' into 10.2Oleksandr Byelkin2019-05-041-0/+1
|\ \ \ | |/ /
| * | MDEV-19351 statistics_for_command_is_needed: Conditional jump or moveIgor Babaev2019-04-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | depends on uninitialised value Initialized THD::force_read_stats introduced in the patch for MDEV-17605. Leaving this field uninitialized in the constructor of the THD class may trigger reading statistical data that is not needed.
* | | Merge branch '10.1' into 10.2Sergei Golubchik2019-03-291-9/+11
|\ \ \ | |/ /
| * | MDEV-18466 Unsafe to log updates on tables referenced by foreign keys with ↵Sergei Golubchik2019-03-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | triggers in statement format ignore FK-prelocked tables when looking for write-prelocked tables with auto-increment to complain about "Statement is unsafe because it invokes a trigger or a stored function that inserts into an AUTO_INCREMENT column"
* | | MDEV-17262: mysql crashed on galera while node rejoined cluster (#895)sysprg2019-03-181-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains a fix for the MDEV-17262/17243 issues and new mtr test. These issues (MDEV-17262/17243) have two reasons: 1) After an intermediate commit, a transaction loses its status of "transaction that registered in the MySQL for 2pc coordinator" (in the InnoDB) due to the fact that since version 10.2 the write_row() function (which located in the ha_innodb.cc) does not call trx_register_for_2pc(m_prebuilt->trx) during the processing of split transactions. It is necessary to restore this call inside the write_row() when an intermediate commit was made (for a split transaction). Similarly, we need to set the flag of the started transaction (m_prebuilt->sql_stat_start) after intermediate commit. The table->file->extra(HA_EXTRA_FAKE_START_STMT) called from the wsrep_load_data_split() function (which located in sql_load.cc) will also do this, but it will be too late. As a result, the call to the wsrep_append_keys() function from the InnoDB engine may be lost or function may be called with invalid transaction identifier. 2) If a transaction with the LOAD DATA statement is divided into logical mini-transactions (of the 10K rows) and binlog is rotated, then in rare cases due to the wsrep handler re-registration at the boundary of the split, the last portion of data may be lost. Since splitting of the LOAD DATA into mini-transactions is technical, I believe that we should not allow these mini-transactions to fall into separate binlogs. Therefore, it is necessary to prohibit the rotation of binlog in the middle of processing LOAD DATA statement. https://jira.mariadb.org/browse/MDEV-17262 and https://jira.mariadb.org/browse/MDEV-17243
* | | Merge branch '10.1' into 10.2Sergei Golubchik2019-03-151-9/+19
|\ \ \ | |/ /
| * | MDEV-15945 --ps-protocol does not test some queriesSergei Golubchik2019-03-121-11/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make mysqltest to use --ps-protocol more use prepared statements for everything that server supports with the exception of CALL (for now). Fix discovered test failures and bugs. tests: * PROCESSLIST shows Execute state, not Query * SHOW STATUS increments status variables more than in text protocol * multi-statements should be avoided (see tests with a wrong delimiter) * performance_schema events have different names in --ps-protocol * --enable_prepare_warnings mysqltest.cc: * make sure run_query_stmt() doesn't crash if there's no active connection (in wait_until_connected_again.inc) * prepare all statements that server supports protocol.h * Protocol_discard::send_result_set_metadata() should not send anything to the client. sql_acl.cc: * extract the functionality of getting the user for SHOW GRANTS from check_show_access(), so that mysql_test_show_grants() could generate the correct column names in the prepare step sql_class.cc: * result->prepare() can fail, don't ignore its return value * use correct number of decimals for EXPLAIN columns sql_parse.cc: * discard profiling for SHOW PROFILE. In text protocol it's done in prepare_schema_table(), but in --ps it is called on prepare only, so nothing was discarding profiling during execute. * move the permission checking code for SHOW CREATE VIEW to mysqld_show_create_get_fields(), so that it would be called during prepare step too. * only set sel_result when it was created here and needs to be destroyed in the same block. Avoid destroying lex->result. * use the correct number of tables in check_show_access(). Saying "as many as possible" doesn't work when first_not_own_table isn't set yet. sql_prepare.cc: * use correct user name for SHOW GRANTS columns * don't ignore verbose flag for SHOW SLAVE STATUS * support preparing REVOKE ALL and ROLLBACK TO SAVEPOINT * don't ignore errors from thd->prepare_explain_fields() * use select_send result for sending ANALYZE and EXPLAIN, but don't overwrite lex->result, because it might be needed to issue execute-time errors (select_dumpvar - too many rows) sql_show.cc: * check grants for SHOW CREATE VIEW here, not in mysql_execute_command sql_view.cc: * use the correct function to check privileges. Old code was doing check_access() for thd->security_ctx, which is invoker's sctx, not definer's sctx. Hide various view related errors from the invoker. sql_yacc.yy: * initialize lex->select_lex for LOAD, otherwise it'll contain garbage data that happen to fail tests with views in --ps (but not otherwise).
| * | MDEV-11975: SQLCOM_PREPARE of EXPLAIN & ANALYZE statement do not return ↵Oleksandr Byelkin2019-03-121-8/+21
| | | | | | | | | | | | | | | | | | correct metadata info Added metadate info after prepare EXPLAIN/ANALYZE.
* | | MDEV-18281 COM_RESET_CONNECTION changes the connection encodingVladislav Vaintroub2019-02-021-0/+1
| | | | | | | | | | | | | | | Store original charset during client authentication, and restore it for COM_RESET_CONNECTION
* | | Merge 10.1 into 10.2Marko Mäkelä2019-02-021-2/+21
|\ \ \ | |/ /
| * | MDEV-14605 Changes to "ON UPDATE CURRENT_TIMESTAMP" fields are notAndrei Elkin2019-01-241-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | always logged properly with binlog_row_image=MINIMAL There are two issues fixed in this commit. The first is an observation of a multi-table UPDATE binlogged in row-format in binlog_row_image=MINIMAL mode. While the UPDATE aims at a table with an ON-UPDATE attribute its binlog after-image misses to record also installed default value. The reason for that turns out missed marking of default-capable fields in TABLE::write_set. This is fixed to mark such fields similarly to 10.2's MDEV-10134 patch (db7edfed17efe6) that introduced it. The marking follows up 93d1e5ce0b841bed's idea to exploit TABLE:rpl_write_set introduced there though, and thus does not mess (in 10.1) with the actual MDEV-10134 agenda. The patch makes formerly arg-less TABLE::mark_default_fields_for_write() to accept an argument which would be TABLE:rpl_write_set. The 2nd issue is extra columns in in binlog_row_image=MINIMAL before-image while merely a packed primary key is enough. The test main.mysqlbinlog_row_minimal always had a wrong result recorded. This is fixed to invoke a function that intended for read_set possible filtering and which is called (supposed to) in all type of MDL, UPDATE including; the test results have gotten corrected. At *merging* from 10.1->10.2 the 1st "main" part of the patch is unnecessary since the bug is not observed in 10.2, so only hunks from sql/sql_class.cc are required.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-01-171-11/+10
|\ \ \ | |/ /
| * | MDEV-18225 Avoid use of LOCK_prepared_stmt_count mutex in Statement_map ↵Vladislav Vaintroub2019-01-151-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | destructo This mutex can be freed when server shuts down (when thread_count goes down to 0) , but it is still used inside THD::~THD() when Statement_map is destroyed. The fix is to call Statement_map::reset() at the point where thread_count is still positive, and avoid locking LOCK_prepared_stmt_count in THD destructor.
| * | Merge branch '11.0' into 10.1Oleksandr Byelkin2018-09-061-1/+2
| |\ \
| | * | extend prelocking to FK-accessed tablesSergei Golubchik2018-09-041-1/+2
| | | | | | | | | | | | | | | | Backport of f1362910980
* | | | MDEV-14576 Include full name of object in message about incorrect value for ↵Alexey Botchkov2018-12-161-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | column. The error message modified. Then the TABLE_SHARE::error_table_name() implementation taken from 10.3, to be used as a name of the table in this message.
* | | | Work around the crash in MDEV-17814Marko Mäkelä2018-12-141-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Internal transactions may not have trx->mysql_thd. But at the same time, trx->duplicates should only hold if REPLACE or INSERT...ON DUPLICATE KEY UPDATE was executed from SQL. The flag feels misplaced. A more appropriate place for it would be row_prebuilt_t or similar.
* | | | MDEV-17073 INSERT…ON DUPLICATE KEY UPDATE became more deadlock-proneMarko Mäkelä2018-11-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | thd_rpl_stmt_based(): A new predicate to check if statement-based replication is active. (This can also hold when replication is not in use, but binlog is.) que_thr_stop(), row_ins_duplicate_error_in_clust(), row_ins_sec_index_entry_low(), row_ins(): On a duplicate key error, only lock all index records when statement-based replication is in use.
* | | | MDEV-14581 Server does not clear diagnostics between sessionsVladislav Vaintroub2018-10-051-0/+5
| | | | | | | | | | | | | | | | | | | | Amend previous patch, so it works in all cases (also for "change user" command, and for RESET CONNECTION in 10.3)
* | | | MDEV-15855 Deadlock between purge thread and DDL statementThirunarayanan Balathandayuthapani2018-07-061-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ======== Truncate operation holds MDL on the table (t1) and tries to acquire InnoDB dict_operation_lock. Purge holds dict_operation_lock and tries to acquire MDL on the table (t1) to evaluate virtual column expressions for indexed virtual columns. It leads to deadlock of purge and truncate table (DDL). Solution: ========= If purge tries to acquire MDL on the table then it should do the following: i) Purge should release all innodb latches (including dict_operation_lock) before acquiring metadata lock on the table. ii) After acquiring metadata lock on the table, it should check whether the table was dropped or renamed. If the table is dropped then purge should ignore the undo log record. If the table is renamed then it should release the old MDL and acquire MDL on the new name. iii) Once purge acquires MDL, it should use the SQL table handle for all the remaining virtual index for the purge record. purge_node_t: Introduce new virtual column information to know whether the MDL was acquired successfully. This is joint work with Marko Mäkelä.
* | | | MDEV-15477: SESSION_SYSVARS_TRACKER does not track last_gtidOleksandr Byelkin2018-06-251-1/+16
| | | | | | | | | | | | | | | | register changes of last_gtid
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-06-211-97/+0
|\ \ \ \ | |/ / /
| * | | MDEV-13577 slave_parallel_mode=optimistic should not report the mode's ↵Sergei Golubchik2018-06-201-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specific temporary errors Revert 7bbe324fc17 Fix the bug differently (in log_event.cc) Fix the test case to actually fail without the bug fix
| * | | Merge branch '10.0' into 10.1Sergei Golubchik2018-06-141-97/+0
| |\ \ \ | | |/ /
| | * | MDEV-15359 Thread stay in "cleaning up" status after finishingSergei Golubchik2018-06-131-97/+0
| | | | | | | | | | | | | | | | | | | | | | | | make thd_get_error_context_description() to show not just thd->proc_info, but exactly the same thread state that SHOW PROCESSLIST shows.
| * | | MDEV-13577 slave_parallel_mode=optimistic should not report the mode'sAndrei Elkin2018-06-121-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specific temporary errors The optimistic parallel slave's worker thread could face a run-time error due to the algorithm's specifics which allows for conflicts like the reported "Can't find record in 'table'". A typical stack is like {noformat} #0 handler::print_error (this=0x61c00008f8a0, error=149, errflag=0) at handler.cc:3650 #1 0x0000555555e95361 in write_record (thd=thd@entry=0x62a0000a2208, table=table@entry=0x61f00008ce88, info=info@entry=0x7fffdee356d0) at sql_insert.cc:1944 #2 0x0000555555ea7767 in mysql_insert (thd=thd@entry=0x62a0000a2208, table_list=0x61b00012ada0, fields=..., values_list=..., update_fields=..., update_values=..., duplic=<optimized out>, ignore=<optimized out>) at sql_insert.cc:1039 #3 0x0000555555efda90 in mysql_execute_command (thd=thd@entry=0x62a0000a2208) at sql_parse.cc:3927 #4 0x0000555555f0cc50 in mysql_parse (thd=0x62a0000a2208, rawbuf=<optimized out>, length=<optimized out>, parser_state=<optimized out>) at sql_parse.cc:7449 #5 0x00005555566d4444 in Query_log_event::do_apply_event (this=0x61200005b9c8, rgi=<optimized out>, query_arg=<optimized out>, q_len_arg=<optimized out>) at log_event.cc:4508 #6 0x00005555566d639e in Query_log_event::do_apply_event (this=<optimized out>, rgi=<optimized out>) at log_event.cc:4185 #7 0x0000555555d738cf in Log_event::apply_event (rgi=0x61d0001ea080, this=0x61200005b9c8) at log_event.h:1343 #8 apply_event_and_update_pos_apply (ev=ev@entry=0x61200005b9c8, thd=thd@entry=0x62a0000a2208, rgi=rgi@entry=0x61d0001ea080, reason=<optimized out>) at slave.cc:3479 #9 0x0000555555d8596b in apply_event_and_update_pos_for_parallel (ev=ev@entry=0x61200005b9c8, thd=thd@entry=0x62a0000a2208, rgi=rgi@entry=0x61d0001ea080) at slave.cc:3623 #10 0x00005555562aca83 in rpt_handle_event (qev=qev@entry=0x6190000fa088, rpt=rpt@entry=0x62200002bd68) at rpl_parallel.cc:50 #11 0x00005555562bd04e in handle_rpl_parallel_thread (arg=arg@entry=0x62200002bd68) at rpl_parallel.cc:1258 {noformat} Here {{handler::print_error}} computes whether to error log the current error when --log-warnings > 1. The decision flag is consulted bu {{my_message_sql()}} which can be eventually called. In the bug case the decision is to log. However in the optimistic mode slave applier case any conflict is attempted to resolve with rollback and retry to success. Hence the logging is at least extraneous. The case is fixed with adding a new flag {{ME_LOG_AS_WARN}} which {{handler::print_error}} may propagate further on through {{my_error}} when the error comes from an optimistically running slave worker thread. The new flag effectively requests the warning level for the errlog record, while the thread's DA records the actual error (which is regarded as temporary one by the parallel slave error handler).
* | | | Fixed memory overrun in binlog_encryption.encrypted_masterMonty2018-05-261-4/+8
| | | | | | | | | | | | | | | | | | | | Problem was that max_row_lengt() used different bitmap than pack_row()
* | | | MDEV-15243 Crash with virtual fields and row based binary loggingMonty2018-05-241-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cause of this was several different bugs: - When using binary logging with binlog_row_image=FULL the all bits in read_set was set, which caused a different (wrong) pattern for marking vcol_set. - TABLE::mark_virtual_columns_for_write() didn't in all cases mark vcol_set with the vcol_field. - TABLE::update_virtual_fields() has to update all vcol fields on REPLACE if binary logging with FULL is used. - VCOL_UPDATE_INDEXED should update all vcol fields part of an index that was not updated by VCOL_UPDATE_FOR_READ - max_row_length() calculated length of NULL and not used fields. This didn't cause any crash, but used more memory than needed.
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-05-201-1/+1
|\ \ \ \ | |/ / /
View Lorry Controller Status