- 19 Jan, 2021 1 commit
-
-
Dmitry Shulga authored
MDEV-24577: Fix warnings generated during compilation of plugin/auth_pam/testing/pam_mariadb_mtr.c on FreeBSD Compiler warnings generated on building MariaDB server for BSD has the same reason as in case building is performed on MacOS. Both platforms do use clang as a C/C++ compiler. So, fix the compiler warnings in case the compiler is clang doesn't matter what kind of building platform do we use for building. This is a follow-up patch for the following bug reports: MDEV-23564: CMAKE failing due to deprecated Apple GSS method MDEV-23935: Fix warnings generated during compilation of plugin/auth_pam/testing/pam_mariadb_mtr.c on MacOS
-
- 14 Jan, 2021 1 commit
-
-
Jan Lindström authored
MDEV-22285 : Assertion `xid_seqno > wsrep_seqno' failed in trx_rseg_update_wsrep_checkpoint on SET @@global.wsrep_start_position Actual assertion mentioned on MDEV seems to be already fixed but setting seqno to -2 will trigger a different assertion mysqld: /home/jan/mysql/10.4-bugs/wsrep-lib/src/server_state.cpp:702: void wsrep::server_state::sst_received(wsrep::client_service&, int): Assertion `state_ == s_joiner || state_ == s_initialized' failed. Fixed this by not allowing user to set seqno < -1 (-1 is special seqno meaning undefined and seqno is initialized to it). MariaDB releases 10.2 and 10.3 already do not allow to set seqno < -1.
-
- 13 Jan, 2021 2 commits
-
-
Jan Lindström authored
MDEV-18542 : galera_sr.galera-features#56: Test failure: signal 6; mysqltest: Can't connect to local MySQL server Make test faster
-
Jan Lindström authored
MDEV-21523 : galera.MDEV-16509 MTR failed: timeout after 900 seconds: Can't connect to local MySQL server Test uses Galera debug sync.
-
- 12 Jan, 2021 2 commits
-
-
Jan Lindström authored
Add wait_condition so that INSERT is replicated before ALTER and ALTER is replicated before we try to INSERT with new number of columns.
-
Varun Gupta authored
The issue here was we were trying to push an extracted condition for a view into the underlying table value constructor inside the view. The fix would be to not push conditions into table value constructors.
-
- 11 Jan, 2021 2 commits
-
-
Marko Mäkelä authored
-
Marko Mäkelä authored
The fix of MDEV-17556 (commit e25623e7 and commit 61a362c9) has been omitted due to conflicts and will have to be applied separately later.
-
- 09 Jan, 2021 2 commits
-
-
Vladislav Vaintroub authored
-
Daniele Sciascia authored
- Galera cluster must be in node 1 and 2, and acts as slave for node 3 - Sync point commit_monitor_enter_sync was renamed to commit_monitor_master_enter_sync in 4.x Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
- 08 Jan, 2021 6 commits
-
-
Jan Lindström authored
A race condition may occur between the execution of transaction commit, and an execution of a KILL statement that would attempt to abort that transaction. MDEV-17092 worked around this race condition by modifying InnoDB code. After that issue was closed, Sergey Vojtovich pointed out that this race condition would better be fixed above the storage engine layer: If you look carefully into the above, you can conclude that thd->free_connection() can be called concurrently with KILL/thd->awake(). Which is the bug. And it is partially fixed in THD::~THD(), that is destructor waits for KILL completion: Fix: Add necessary mutex operations to THD::free_connection() and move WSREP specific code also there. This ensures that no one is using THD while we do free_connection(). These mutexes will also ensures that there can't be concurrent KILL/THD::awake(). innobase_kill_query We can now remove usage of trx_sys_mutex introduced on MDEV-17092. trx_t::free() Poison trx->state and trx->mysql_thd This patch is validated with an RQG run similar to the one that reproduced MDEV-17092.
-
Marko Mäkelä authored
-
Nikita Malyavin authored
-
Jan Lindström authored
-
Marko Mäkelä authored
-
Nikita Malyavin authored
The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_*, all_set bitmaps are never substituted already. This patch changes the following function prototypes: * tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps.
-
- 07 Jan, 2021 4 commits
-
-
Alice Sherepa authored
MDEV-16272 rpl.rpl_semisync_ali_issues failed in buildbot, SHOW variable was done instead of waiting for the value of that variable
-
Alexey Yurchenko authored
Ensure consistent use of logging macros in wsrep-related code Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
Oleksandr Byelkin authored
Use the same variable in both scopes (from where we have "goto error" and target of the goto)
-
Nikita Malyavin authored
Problem: Assertion `transactional_table || !changed || thd->transaction.stmt.modified_non_trans_table' failed due REPLACE into a versioned table. It is not specific to system versioning/pertitioning/heap, but this combination makes it much easier to reproduce. The thing is to make first ha_update_row call succeed to make info->deleted != 0. And then make REPLACE fail by any reason. In this scenario we overflow versioned partition, so next ha_update_row succeeds, but corresponding ha_write_row fails to insert history record. Fix: modified_non_trans_table is set in one missed place
-
- 06 Jan, 2021 1 commit
-
-
Andrei Elkin authored
fixing windows build.
-
- 05 Jan, 2021 3 commits
-
-
Nikita Malyavin authored
mysql_col_offset was not updated after the new column has been added by an INSTANT ALTER TABLE -- table data dictionary had been remaining the same. When the virtual column is added or removed, table was usually evicted and then reopened, which triggered vcol info rebuild on the next open. However this also should be done when the usual column is added or removed: mariadb always stores virtual field at the end of maria record, so the shift should always happen. Fix: expand the eviction condition to the case when usual fields are added/removed Note: this should happen only in the case of !new_clustered: * When new_clustered is true, a new data dictionary is created, and vcol metadata is rebuilt in `alter_rebuild_apply_log()` * We can't do it in `new_clustered` case, because the old table is not yet subctituted correctly
-
Nikita Malyavin authored
-
Nikita Malyavin authored
-
- 04 Jan, 2021 8 commits
-
-
Stepan Patryshev authored
-
Stepan Patryshev authored
-
Stepan Patryshev authored
-
Stepan Patryshev authored
-
Stepan Patryshev authored
-
Stepan Patryshev authored
-
Sujatha authored
Problem: ======= Upon deleting or updating a row in a parent table (with primary key), if the child table has virtual column and an associated key with ON UPDATE CASCADE/ON DELETE CASCADE, it will result in slave crash. Analysis: ======== Tables which are related through foreign key require prelocking similar to triggers. i.e If a table has triggers/foreign keys we should add all tables and routines used by them to the prelocking set. This prelocking happens during 'open_and_lock_tables' call. Each table being opened is checked for foreign key references. If foreign key reference exists then the child table is opened and it is linked to the table_list. Upon any modification to parent table its corresponding child tables are retried from table_list and they are updated accordingly. This prelocking work fine on master. On slave prelocking works for following cases. - Statement/mixed based replication - In row based replication when trigger execution is enabled through 'slave_run_triggers_for_rbr=YES/LOGGING/ENFORCE' Otherwise it results in an assert/crash, as the parent table will not find the corresponding child table and it will be NULL. Dereferencing NULL pointer leads to slave server exit. Fix: === Introduce a new 'slave_fk_event_map' flag similar to 'trg_event_map'. This flag will ensure that when foreign key is enabled in row based replication all the parent and child tables are prelocked, so that parent is able to locate the child table. Note: This issue is specific to slave, hence only slave needs to be upgraded.
-
Rucha Deodhar authored
-
- 02 Jan, 2021 3 commits
-
-
Marko Mäkelä authored
btr_discard_only_page_on_level(): Attempt to read the MDEV-15562 metadata record from the leaf page, not the root page. In the root, the leftmost (in this case, the only) node pointer would look like a metadata record. This corruption bug was introduced in commit 0e5a4ac2 (MDEV-15562). The scenario is rare: a column was dropped instantly or the order of columns was changed instantly, and then the table became empty in such a way that in the last step, the root page had one child page. Normally, a non-leaf B-tree page would always contain at least 2 children.
-
Marko Mäkelä authored
Let us use Intel intrinsic functions in WolfSSL whenever possible. This allows such code to be compiled WITH_MSAN.
-
Marko Mäkelä authored
-
- 31 Dec, 2020 1 commit
-
-
Rucha Deodhar authored
Analysis: select into outfile creates files everytime with 666 permission, regardsless if umask environment variables and umask settings on OS level. It seems hardcoded. Fix: change 0666 to 0644 which will let anybody consume the file but not change it.
-
- 29 Dec, 2020 2 commits
-
-
Oleksandr Byelkin authored
-
Igor Babaev authored
(correction for commit 6fed6de9)
-
- 28 Dec, 2020 2 commits
-
-
Teemu Ollakka authored
Under ps-protocol, commandsl like COM_STMT_FETCH, COM_STMT_CLOSE and COM_STMT_SEND_LONG_DATA are not supposed to return errors. Therefore, if a transaction is BF aborted and the client is processing one of those commands, then we should not return a deadlock error immediately. Instead wait for the a subsequent client interaction which permits errors to be returned. To handle this, wsrep_before_command() now accepts parameter keep_command_error. If set true, keep_command_error will cause wsrep-lib side to skip result handling, and to keep the current error for the next interaction with the client. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
-
Marko Mäkelä authored
-