summaryrefslogtreecommitdiff
path: root/storage
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-22775 [HY000][1553] Changing name of primary key column with foreign ↵bb-10.4-bar-MDEV-22775Alexander Barkov2021-03-251-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | key constraint fails. Problem: The problem happened because of a conceptual flaw in the server code: a. The table level CHARSET/COLLATE clause affected all data types, including numeric and temporal ones: CREATE TABLE t1 (a INT) CHARACTER SET utf8 [COLLATE utf8_general_ci]; In the above example, the Column_definition_attributes (and then the FRM record) for the column "a" erroneously inherited "utf8" as its character set. b. The "ALTER TABLE t1 CONVERT TO CHARACTER SET csname" statement also erroneously affected Column_definition_attributes::charset for numeric and temporal data types and wrote "csname" as their character set into FRM files. So now we have arbitrary non-relevant charset ID values for numeric and temporal data types in all FRM files in the world :) The code in the server and the other engines did not seem to be affected by this flaw. Only InnoDB inplace ALTER was affected. Solution: Fixing the code in the way that only character string data types (CHAR,VARCHAR,TEXT,ENUM,SET): - inherit the table level CHARSET/COLLATE clause - get the charset value according to "CONVERT TO CHARACTER SET csname". Numeric and temporal data types now always get &my_charset_numeric in Column_definition_attributes::charset and always write its ID into FRM files: - no matter what the table level CHARSET/COLLATE clause is, and - no matter what "CONVERT TO CHARACTER SET" says. Details: 1. Adding helper classes to pass small parts of HA_CREATE_INFO into Type_handler methods: - Column_derived_attributes - to pass table level CHARSET/COLLATE, so columns that do not have explicit CHARSET/COLLATE clauses can derive them from the table level, e.g. CREATE TABLE t1 (a VARCHAR(1), b CHAR(1)) CHARACTER SET utf8; - Column_bulk_alter_attributes - to pass bulk attribute changes generated by the ALTER related code. These bulk changes affect multiple columns at the same time: ALTER TABLE ... CONVERT TO CHARACTER SET csname; Note, passing the whole HA_CREATE_INFO directly to Type_handler would not be good: HA_CREATE_INFO is huge and would need not desired dependencies in sql_type.h and sql_type.cc. The Type_handler API should use smallest possible data types! 2. Type_handler::Column_definition_prepare_stage1() is now responsible to set Column_definition::charset properly, according to the data type, for example: - For string data types, Column_definition_attributes::charset is set from the table level CHARSET/COLLATE clause (if not specified explicitly in the column definition). - For numeric and temporal fields, Column_definition_attributes::charset is set to &my_charset_numeric, no matter what the table level CHARSET/COLLATE says. - For GEOMETRY, Column_definition_attributes::charset is set to &my_charset_bin, no matter what the table level CHARSET/COLLATE says. Previously this code (setting `charset`) was outside of of Column_definition_prepare_stage1(), namely in mysql_prepare_create_table(), and was erroneously called for all data types. 3. Adding Type_handler::Column_definition_bulk_alter(), to handle "ALTER TABLE .. CONVERT TO". Previously this code was inside get_sql_field_charset() and was erroneously called for all data types. 4. Removing the Schema_specification_st parameter from Type_handler::Column_definition_redefine_stage1(). Column_definition_attributes::charset is now fully properly initialized by Column_definition_prepare_stage1(). So we don't need access to the table level CHARSET/COLLATE clause in Column_definition_redefine_stage1() any more. 5. Other changes: - Removing global function get_sql_field_charset() - Moving the part of the former get_sql_field_charset(), which was responsible to inherit the table level CHARSET/COLLATE clause to new methods: -- Column_definition_attributes::explicit_or_derived_charset() and -- Column_definition::prepare_charset_for_string(). This code is only needed for string data types. Previously it was erroneously called for all data types. - Moving another part, which was responsible to apply the "CONVERT TO" clause, to Type_handler_general_purpose_string::Column_definition_bulk_alter(). - Replacing the call for get_sql_field_charset() in sql_partition.cc to sql_field->explicit_or_derived_charset() - it is perfectly enough. The old code was redundant: get_sql_field_charset() was called from sql_partition.cc only when there were no a "CONVERT TO CHARACTER SET" clause involved, so its purpose was only to inherit the table level CHARSET/COLLATE clause. - Moving the code handling the BINCMP_FLAG flag from mysql_prepare_create_table() to Column_definition::prepare_charset_for_string(): This code is responsible to resolve the BINARY comparison style into the corresponding _bin collation, to do the following transparent rewrite: CREATE TABLE t1 (a VARCHAR(10) BINARY) CHARSET utf8; -> CREATE TABLE t1 (a VARCHAR(10) CHARACTER SET utf8 COLLATE utf8_bin); This code is only needed for string data types. Previously it was erroneously called for all data types. 6. Renaming Table_scope_and_contents_source_pod_st::table_charset to alter_table_convert_to_charset, because the only purpose it's used for is handlering "ALTER .. CONVERT". The new name is much more self-descriptive.
* Merge 10.3 into 10.4Marko Mäkelä2021-03-197-158/+246
|\
| * MDEV-25125 Assertion failure in fetch_data_into_cache_low()Marko Mäkelä2021-03-181-4/+7
| | | | | | | | | | | | | | | | | | | | Before MDEV-14638, there was no race condition between the execution of fetch_data_into_cache() and transaction commit. fetch_data_into_cache(): Acquire trx_t::mutex before checking trx_t::state, to prevent a concurrent transition from TRX_STATE_COMMITTED_IN_MEMORY to TRX_STATE_NOT_STARTED in trx_commit_in_memory().
| * Merge 10.2 into 10.3Marko Mäkelä2021-03-186-177/+269
| |\
| | * MDEV-10682 Race condition between ANALYZE and STATS_AUTO_RECALCMarko Mäkelä2021-03-181-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ha_innobase::info_low(): While collecting statistics for ANALYZE TABLE, ensure that dict_stats_process_entry_from_recalc_pool() is not executing on the same table. We observed result differences for the test innodb.innodb_stats because dict_stats_empty_index() was being invoked by the background statistics calculation while ha_innobase::analyze() was executing dict_stats_analyze_index_level().
| | * MDEV-25121: innodb_flush_method=O_DIRECT fails on compressed tablesMarko Mäkelä2021-03-181-13/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tests with 4096-byte sector size confirm that it is safe to use O_DIRECT with page_compressed tables. That had been disabled on Linux, in an attempt to fix MDEV-21584 which had been filed for the O_DIRECT problems earlier. The fil_node_t::block_size was being set mostly correctly until commit 10dd290b4b8b8b235c8cf42e100f0a4415629e79 (MDEV-17380) introduced a regression in MariaDB Server 10.4.4. fil_node_t::read_page0(): Initialize fil_node_t::block_size. This will probably make similar code in fil_space_extend_must_retry() redundant, but we play it safe and will not remove that code. Thanks to Vladislav Vaintroub for testing this on Microsoft Windows using an old-fashioned rotational hard disk with 4KiB sector size. Reviewed by: Vladislav Vaintroub
| | * MDEV-21584 - portability fixVladislav Vaintroub2021-03-181-1/+3
| | | | | | | | | | | | This patch implements OS_DATA_FILE_NO_O_DIRECT on Windows.
| | * Cleanup: Remove unused OS_DATA_TEMP_FILEMarko Mäkelä2021-03-182-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This had been originally added in mysql/mysql-server@192bb153b675fe09037a53e456a79eee7211e3a7 with the motivation to disable O_DIRECT for the dedicated tablespace for temporary tables. In MariaDB Server, commit 5eb539555b36a60944eefeb84d5d6d436ba61e63 (MDEV-12227) should be a better solution. The code became orphaned later in mysql/mysql-server@c61244c0e6c58727cffebfb312ac415a463fa0fe and it had been applied to MariaDB Server 10.2.2 in commit 2e814d4702d71a04388386a9f591d14a35980bfe and commit fec844aca88e1c6b9c36bb0b811e92d9d023ffb9. Thanks to Vladislav Vaintroub for spotting this.
| | * switch off storage/innobase/.clang-format: InnoDB uses a common formatting ↵Eugene Kosov2021-03-171-0/+0
| | | | | | | | | | | | style for all new code
| | * MDEV-24978 : SIGABRT in __libc_messageJan Lindström2021-03-151-21/+42
| | | | | | | | | | | | | | | | | | Keyvalue can be longer than REC_VERSION_56_MAX_INDEX_COL_LEN and this leads out-of-array reference. Use dynamic memory allocation using actual max length of key value.
| | * MDEV-25101 Assertion !strcmp(field->name, "table_name") failedMarko Mäkelä2021-03-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | btr_node_ptr_max_size(): Let us remove the debug assertion that was added in MDEV-14637. The assertion assumed that no additional indexes exist in mysql.innodb_index_stats or mysql.innodb_table_stats. The code path is working around an incorrect definition of a table, interpreting VARCHAR(64) as the more correct VARCHAR(199). No test case will be added, because MDEV-24579 proves that executing DDL on the statistics tables involves a race condition. The test case included the following: ALTER TABLE mysql.innodb_index_stats ADD KEY (stat_name); CREATE TABLE t (a INT) ENGINE=InnoDB STATS_PERSISTENT=1;
| | * MDEV-24853: Duplicate key generated during cluster configuration changeJulius Goryavsky2021-03-081-131/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Incorrect processing of an auto-incrementing field in the WSREP-related code during applying transactions results in a duplicate key being created. This is due to the fact that at the beginning of the write_row() and update_row() functions, the values of the auto-increment parameters are used, which are read from the parameters of the current thread, but further along the code other values are used, which are read from global variables (when applying a transaction). This can happen when the cluster configuration has changed while applying a transaction (for example in the high_priority_service mode for Galera 4). Further during IST processing duplicating key is detected, and processing of the DB_DUPLICATE_KEY return code (inside innodb, in the write_row() handler) results in a call to the wsrep_thd_self_abort() function.
* | | MDEV-25121: innodb_flush_method=O_DIRECT fails on compressed tablesMarko Mäkelä2021-03-183-31/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tests with 4096-byte sector size confirm that it is safe to use O_DIRECT with page_compressed tables. That had been disabled on Linux, in an attempt to fix MDEV-21584 which had been filed for the O_DIRECT problems earlier. The fil_node_t::block_size was being set mostly correctly until commit 10dd290b4b8b8b235c8cf42e100f0a4415629e79 (MDEV-17380) introduced a regression in MariaDB Server 10.4.4. fil_node_open_file(): Only avoid setting O_DIRECT on ROW_FORMAT=COMPRESSED tables that use KEY_BLOCK_SIZE=1 or 2 (1024 or 2048 bytes). fil_ibd_create(): Avoid setting O_DIRECT on ROW_FORMAT=COMPRESSED tables that use KEY_BLOCK_SIZE=1 or 2 (1024 or 2048 bytes). fil_node_t::find_metadata(): Require fstat() to be always invoked outside Microsoft Windows, so that fil_node_t::block_size can be set. fil_node_t::read_page0(): Rely on find_metadata() to assign block_size. Thanks to Vladislav Vaintroub for testing this on Microsoft Windows using an old-fashioned rotational hard disk with 4KiB sector size. Reviewed by: Vladislav Vaintroub This is a port of commit 00f620b27e960c4b96a8392b27742fd5e41a69e3 and commit 6505662c23ba81331d91f65c18e06a759d6f148f from 10.2.
* | | Merge 10.3 into 10.4Marko Mäkelä2021-03-185-41/+78
|\ \ \ | |/ /
| * | MDEV-24730 Insert log operation fails after purge resets n_core_fieldsThirunarayanan Balathandayuthapani2021-03-125-32/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Online log for insert operation of redundant table fails with index->is_instant() assert. Purge can reset the n_core_fields when alter is waiting to upgrade MDL for commit phase of DDL. In the meantime, any insert DML tries to log the operation fails with index is not being instant. row_log_get_n_core_fields(): Get the n_core_fields of online log for the given index. rec_get_converted_size_comp_prefix_low(): Use n_core_fields of online log when InnoDB calculates the size of data tuple during redundant row format table rebuild. rec_convert_dtuple_to_rec_comp(): Use n_core_fields of online log when InnoDB does the conversion of data tuple to record during redudant row format table rebuild. - Adding the test case which has more than 129 instant columns.
* | | Merge 10.3 into 10.4Marko Mäkelä2021-03-112-4/+36
|\ \ \ | |/ /
| * | MDEV-25106 Deprecation warning for innodb_checksum_algorithm=none,innodb,...Marko Mäkelä2021-03-111-3/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-25105 (commit 7a4fbb55b02b449a135fe935f624422eaacfdd7c) in MariaDB 10.6 will refuse the innodb_checksum_algorithm values none, innodb, strict_none, strict_innodb. We will issue a deprecation warning if innodb_checksum_algorithm is set to any of these non-default unsafe values. innodb_checksum_algorithm=crc32 was made the default in MySQL 5.7 and MariaDB Server 10.2, and given that older versions of the server have reached their end of life, there is no valid reason to use anything else than innodb_checksum_algorithm=crc32 or innodb_checksum_algorithm=strict_crc32 in MariaDB 10.3. Reviewed by: Sergei Golubchik
| * | MDEV-25070 SIGSEGV in fts_create_in_mem_aux_tableThirunarayanan Balathandayuthapani2021-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | | InnoDB set the space in dict_table_t as NULL when table is discarded. So InnoDB shouldn't use the space present in table to detect whether the given tablespace is temporary tablespace.
* | | MDEV-25107 Check TABLE miscalutates the length of columnThirunarayanan Balathandayuthapani2021-03-111-2/+2
| | | | | | | | | | | | | | | | | | - This is caused by merge commit a26e7a37266d8296094dabca52f0f6646fd73926. InnoDB fails to fetch the next index field when there is a externally stored column length check involved.
* | | MDEV-25057 Assertion `n_fields < dtuple_get_n_fields(entry)'Thirunarayanan Balathandayuthapani2021-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | failed in dtuple_convert_big_rec In dtuple_convert_big_rec(), InnoDB fails to consider the instant metadata blob while choosing the variable length field.
* | | mark Aria allocations for temp tables as MY_THREAD_SPECIFICSergei Golubchik2021-03-089-63/+81
| | |
* | | Merge 10.3 into 10.4Marko Mäkelä2021-03-086-58/+55
|\ \ \ | |/ /
| * | Merge 10.2 into 10.3Marko Mäkelä2021-03-054-47/+24
| |\ \ | | |/
| | * fixup 58b56f14a096285a0e51b2233fc35398f1b01f5a: Remove dead codeMarko Mäkelä2021-03-043-33/+6
| | | | | | | | | | | | | | | | | | | | | row_prebuilt_t::m_no_prefetch: Remove (it was always false). row_prebuilt_t::m_read_virtual_key: Remove (it was always false). Only ha_innopart ever set these fields.
| | * MDEV-25051 Race condition between persistent statistics and RENAME TABLE or ↵Marko Mäkelä2021-03-041-14/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TRUNCATE innobase_rename_table(): Invoke dict_stats_wait_bg_to_stop_using_table() to ensure that dict_stats_update() cannot be accessing the table name that we will be modifying. If we are executing RENAME rather than TRUNCATE, reset the flag at the end so that persistent statistics can be calculated again. The race condition was encountered with ASAN and rr. Sorry, there is no test case, like there is for nothing related to dict_stats_wait_bg_to_stop_using_table(). The entire code is an ugly work-around for the failure of dict_stats_process_entry_from_recalc_pool() to acquire MDL. Note: It appears that an ALTER TABLE that is not rebuilding the table will fail to reset the flag that blocks the processing of statistics.
| * | Merge branch '10.2' into 10.3Vicențiu Ciorbaru2021-03-042-10/+32
| |\ \ | | |/
| | * MDEV-24748 extern column check missing in btr_index_rec_validate()Thirunarayanan Balathandayuthapani2021-03-031-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | In btr_index_rec_validate(), externally stored column check is missing while matching the length of the field with the length of the field data stored in record. Fetch the length of the externally stored part and compare it with the fixed field length.
| | * MDEV-20648 InnoDB: Failing assertion: !(*node)->being_extended, ↵bb-10.2-MDEV-20648Thirunarayanan Balathandayuthapani2021-03-031-14/+26
| | | | | | | | | | | | | | | | | | | | | innodb.log_data_file_size failed in buildbot, assertion `!space->is_stopping()' InnoDB should check whether the tablespace is being deleted while extending the tablespace.
* | | Remove unused HA_EXTRA_FAKE_START_STMTMarko Mäkelä2021-03-052-7/+0
| | | | | | | | | | | | This is fixup for commit f06a0b5338694755842a58798bb3a9a40da78bfd.
* | | Merge 10.3 into 10.4Marko Mäkelä2021-03-055-39/+41
|\ \ \ | |/ /
| * | MDEV-24811 Assertion find(table) failed with innodb_evict_tables_on_commit_debugMarko Mäkelä2021-03-032-46/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a backport of commit 18535a402817d8a2b8452df0f75c15dda9199acb from 10.6. lock_release(): Implement innodb_evict_tables_on_commit_debug. Before releasing any locks, collect the identifiers of tables to be evicted. After releasing all locks, look up for the tables and evict them if it is safe to do so. trx_commit_in_memory(): Invoke trx_update_mod_tables_timestamp() before lock_release(), so that our locks will protect the tables from being evicted.
| * | Merge 10.2 into 10.3Marko Mäkelä2021-03-031-2/+3
| |\ \ | | |/
| | * MDEV-24532 Table corruption ER_NO_SUCH_TABLE_IN_ENGINE .. on table with ↵Monty2021-03-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | foreign key When doing a truncate on an Innodb under lock tables, InnoDB would rename the old table to #sql-... and recreate a new 't1' table. The table lock would still be on the #sql-table. When doing ALTER TABLE, Innodb would do the changes on the #sql table (which would disappear on close). When the SQL layer, as part of inline alter table, would close the original t1 table (#sql in InnoDB) and then reopen the t1 table, Innodb would notice that this does not match it's own (old) t1 table and generate an error. Fixed by adding code in truncate table that if we are under lock tables and truncating an InnoDB table, we would close, reopen and lock the table after truncate. This will remove the #sql table and ensure that lock tables is using the new empty table. Reviewer: Marko Mäkelä
| * | Fixed printing of wring filname "maria_open" in maria.maria-recovery2.testMonty2021-03-012-0/+2
| | | | | | | | | | | | | | | | | | | | | eprintf() was missing a va_start(), which caused wrong filename to be printed when printing recovery trace. Added also missing new line when printing "Table is crashed" to trace file
* | | MDEV-24967 : Signal 11 on ha_innodb.cc::bg_wsrep_kill_trx line 18611Jan Lindström2021-02-241-4/+6
| | | | | | | | | | | | | | | Null poiter reference in case where bf_thd has no trx .e.g. when we have MDL-conflict.
* | | MDEV-20857: perf schema conflict name filename_hashDaniel Black2021-02-243-13/+13
| | | | | | | | | | | | | | | | | | | | | filename_hash is a function from libiberty.a from the system but also an expored name in the perf schema static library. We'll use a different name.
* | | Merge 10.3 into 10.4Marko Mäkelä2021-02-231-2/+1
|\ \ \ | |/ /
| * | Merge 10.2 into 10.3Marko Mäkelä2021-02-231-2/+1
| |\ \ | | |/
| | * MDEV-24913 Assertion !recv_no_log_write in log_write_up_to()Thirunarayanan Balathandayuthapani2021-02-231-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | - The commit 5fd3c7471e3e0673b50d309567c9747d36f09412(MDEV-24709) resets the recv_no_ibuf_operations in recv_recovery_from_checkpoint_start(), but InnoDB fails to reset the variable recv_no_log_write() during that time and that leads to the assert failure.
* | | Merge branch '10.3' into 10.4Sergei Golubchik2021-02-235-20/+98
|\ \ \ | |/ /
| * | Merge branch '10.2' into 10.3Sergei Golubchik2021-02-226-21/+99
| |\ \ | | |/
| | * Merge branch 'bb-10.2-release' into 10.2Sergei Golubchik2021-02-2214-306/+500
| | |\
| | * | MDEV-24863 AHI entries mismatch with the index while reloading the evicted ↵Thirunarayanan Balathandayuthapani2021-02-221-14/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tables. - This is caused by commit ad6171b91cac33e70bb28fa6865488b2c65e858c (MDEV-22456). InnoDB reloads the evicted table again from dictionary. In that case, AHI entries and current index object mismatches happens. When index object mismatches then InnoDB should drop the page hash AHI entries for the block. In btr_search_drop_page_hash_index(), InnoDB should take exclusive lock on the AHI latch if index is already freed to avoid the freed memory access during buf_pool_resize()
| | * | MDEV-24873 : galera.galera_as_slave_ctas MTR failed: Assertion ↵Jan Lindström2021-02-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `(&(&LOCK_thd_data)->m_mutex)->count > 0 && pthread_equal(pthread_self(), (&(&LOCK_thd_data)->m_mutex)->thread)' failed in sql_class.cc on THD::awake(killed_state) Problem was that thd::awake assumes now that you hold THD::LOCK_thd_data so we need to keep it when we call wsrep_thd_awake from wsrep_abort_transaction.
| | * | MDEV-24763 ALTER TABLE fails to rename a column in SYS_FIELDSMarko Mäkelä2021-02-121-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | innobase_rename_column_try(): When renaming SYS_FIELDS records for secondary indexes, try to use both formats of SYS_FIELDS.POS as keys, in case the PRIMARY KEY includes a column prefix. Without this fix, an ALTER TABLE that renames a column followed by a server restart (or LRU eviction of the table definition from dict_sys) would make the table inaccessible.
| | * | MDEV-24790 CAST('0e1111111111' AS DECIMAL(38,0)) returns a wrong resultAlexander Barkov2021-02-081-3/+2
| | | |
| | * | Updating test results in rocksdb test suite after MDEV-11172 is fixedVarun Gupta2021-02-013-5/+5
| | | |
* | | | Merge branch 'bb-10.4-release' into 10.4Sergei Golubchik2021-02-23147-2503/+19080
|\ \ \ \
| * | | | remove find_thread_with_thd_data_lock_callbackSergei Golubchik2021-02-121-2/+4
| | | | | | | | | | | | | | | | | | | | let the caller take the lock if needed
| * | | | MDEV-23328 Server hang due to Galera lock conflict resolutionSergei Golubchik2021-02-121-60/+148
| | | | | | | | | | | | | | | | | | | | adaptation of 29bbcac0ee8 for 10.4
View Lorry Controller Status