An error occurred fetching the project authors.
- 15 Jan, 2021 4 commits
-
-
Monty authored
- Create_tmp_table::finalize didn't clear file after delete which could cause a double free. This is however not a likely problem as this code path is very unlikely to happen - free_tmp_table() could do handler calls even if the table was never opened. Fixed by adding a test if the table is opened.
-
Marko Mäkelä authored
The table performance_schema.events_transactions_history_long that was imported from MySQL 5.7.28 in commit 0ea717f5 may report bogus trx_id values for InnoDB transactions. innobase_register_trx(): Pass trx->id to trans_register_ha(), even if it is 0. It is more appropriate to report NULL than some arbitrary value that has been constructed from the address of a transaction identifier.
-
David Carlier authored
closes #1737 Reviewers: Marko Mäkelä, Krunal Bauskar
-
pkubaj authored
Fixes build on powerpc64 and powerpc64le. Closes: #1710
-
- 14 Jan, 2021 1 commit
-
-
Marko Mäkelä authored
Starting with MDEV-15528, we will avoid writing freed pages back to data files. During stress testing, the assertion mach_read_from_4(frame + 4U) == block.page.id().page_no() failed in log_phys_t::apply(), because before the server was killed and restarted, change buffer merge was executed on a previously freed page. During recovery, the assertion would fail when InnoDB would apply a FREE_PAGE and a WRITE record to the page. ibuf_merge_or_delete_for_page(): Before applying any changes, check whether the secondary index leaf page has already been freed according to the allocation bitmap page. If it is freed, then we must reset the bits in change buffer bitmap page. ibuf_reset_bitmap(): Auxiliary function for repeated code. mtr_t::sx_lock_space(): Replaces mtr_t::x_lock_space(). Due to the lazy approach of the change buffer, The function ibuf_merge_or_delete_for_page() may be executed in buf_page_create() while the tablespace is already X-latched. An S-latch must not be acquired while the thread already holds an X-latch, but a redundant SX-latch is fine. The fix was developed by Thirunarayanan Balathandayuthapani.
-
- 13 Jan, 2021 1 commit
-
-
Marko Mäkelä authored
The parameter innodb_idle_flush_pct that was introduced in MariaDB Server 10.1.2 by MDEV-6932 has no effect ever since the InnoDB changes from MySQL 5.7.9 were applied in commit 2e814d47. Let us declare the parameter as MARIADB_REMOVED_OPTION. For earlier versions, commit ea9cd97f declared the parameter deprecated.
-
- 12 Jan, 2021 7 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
4. update columnstore
-
Sergei Golubchik authored
3. Embed plugin version into the DEB package version this assumes that -DDEB is only used from within autobake-deb.sh
-
Sergei Golubchik authored
and not ${binary:Version}, which is the version of the current package, whatever it is.
-
Sergei Golubchik authored
2. Embed plugin version into the RPM package version introduce SERVER_VERSION, because plugins can overwrite VERSION (and columnstore actually does)
-
Sergei Golubchik authored
1. specify plugin version in MYSQL_ADD_PLUGIN
-
- 11 Jan, 2021 3 commits
-
-
Marko Mäkelä authored
-
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.
-
- 10 Jan, 2021 1 commit
-
-
Brad Smith authored
Reviewer: Daniel Black
-
- 09 Jan, 2021 3 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>
-
Jan Lindström authored
MDEV-24546 : AddressSanitizer: initialization-order-fiasco on address ... in Sys_var_integer from __static_initialization_and_destruction_0, possibly inside global var wsrep_gtid_server Galera parameter wsrep_gtid_domain_id was defined using a class where actual parameter was not a first member. Fixed this by using normal variable and assigning this value to class member value.
-
- 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 5 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>
-
Marko Mäkelä authored
buf_LRU_get_free_block(): Increment the counter after acquiring buf_pool.mutex. buf_pool.stat.LRU_waits: Replaces export_vars.innodb_buffer_pool_wait_free and srv_stats.buf_pool_wait_free. Reads of the counter will remain dirty, not acquiring the mutex.
-
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 3 commits
-
-
Andrei Elkin authored
fixing windows build.
-
Marko Mäkelä authored
In commit 3a9a3be1 (MDEV-23855) some previous logic was replaced with the condition dirty_pct < srv_max_dirty_pages_pct_lwm, which caused the default value of the parameter innodb_max_dirty_pages_pct_lwm=0 to lose its special meaning: 'refer to innodb_max_dirty_pages_pct instead'. This implicit special meaning was visible in the function af_get_pct_for_dirty(), which was removed in commit f0c295e2 (MDEV-24369). page_cleaner_flush_pages_recommendation(): Restore the special meaning that was removed in MDEV-24369. buf_flush_page_cleaner(): If srv_max_dirty_pages_pct_lwm==0.0, refer to srv_max_buf_pool_modified_pct. This fixes the observed performance regression due to excessive page flushing. buf_pool_t::page_cleaner_wakeup(): Revise the wakeup condition. innodb_init(): Do initialize srv_max_io_capacity in Mariabackup. It was previously constantly 0, which caused mariadb-backup --prepare to hang in buf_flush_sync(), making no progress.
-
Oleksandr Byelkin authored
-
- 05 Jan, 2021 4 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
-
Stepan Patryshev authored
-
- 04 Jan, 2021 2 commits
-
-
Stepan Patryshev authored
-
Stepan Patryshev authored
-