- 22 Mar, 2019 3 commits
-
-
Sergei Golubchik authored
-
Marko Mäkelä authored
MDEV-18224 MTR's internal check of the test case 'innodb.recovery_shutdown' failed due to extra #sql-ib*.ibd files The test innodb.recovery_shutdown would occasionally fail, because recovered incomplete transactions would be conflicting with DROP TABLE, causing the background drop table queue to be invoked. Add a slow shutdown before dropping the tables, so that the recovered transactions will be rolled back. Starting with MDEV-14705, normal shutdown would abort the rollback of recovered transactions.
-
Marko Mäkelä authored
-
- 21 Mar, 2019 10 commits
-
-
FaramosCZ authored
The file will be closed on line 540
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
trx_rseg_header_create(): Return the block descriptor, and remove the redundant trx_rsegf_get_new() call. Apparently the idea of that call was some kind of encapsulation or abstraction, to discourage the direct use of the constant TRX_RSEG. This also removes the trx_purge_initiate_truncate() local variable rseg_header, which was only used in debug builds.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
Alexander Barkov authored
Tests for MDEV-18892 failed, because of extra 'Prepare' and 'Close stmt' entries in the output. Filtering out PS related entries (where it is necessary).
-
- 20 Mar, 2019 2 commits
-
-
Marko Mäkelä authored
row_ins_foreign_fill_virtual(): Construct update->old_vrow with ROW_COPY_DATA instead of ROW_COPY_POINTERS. With the latter, the object would be pointing to a buffer pool page frame. That page frame can become stale and invalid as soon as row_ins_foreign_check_on_constraint() invokes mtr_t::commit(). Most of the time, the pointer target is not going to be overwritten by anything, and everything appears to work correctly. Buffer pool page replacement is highly unlikely, and any pessimistic operation that would overwrite the old location of the record is only slightly more likely. It is not known whether there is an actual bug. This came up while diagnosing MDEV-18879 in MariaDB 10.3.
-
Alexander Barkov authored
Adding an intermediate volatile variable to avoid using co-processor registers on some platforms (e.g. 32-bit x86). This change makes test results stable accross all platforms.
-
- 19 Mar, 2019 3 commits
-
-
Marko Mäkelä authored
MariaDB Server 10.0 and 10.1 support non-indexed virtual columns, which are hidden from the storage engine. Starting with MDEV-5800 in MariaDB 10.2.2, the virtual columns are visible to storage engines. calc_row_difference(): Follow up the MDEV-17199 fix, which forgot to increment num_v when skipping virtual columns in tables that were created before MariaDB 10.2.2. This caused a corruption of the update vector when an updated persistent column is preceded by virtual columns.
-
Marko Mäkelä authored
The macro innobase_is_v_fld() turns out to be equivalent with the opposite of Field::stored_in_db(). Remove the macro and invoke the member function directly. innodb_base_col_setup_for_stored(): Simplify a condition to only check Field::vcol_info. innobase_create_index_def(): Replace some redundant code with DBUG_ASSERT().
-
Marko Mäkelä authored
MariaDB before MDEV-5800 in version 10.2.2 did not support indexed virtual columns. Non-persistent virtual columns were hidden from storage engines. Only starting with MDEV-5800, InnoDB would create internal metadata on virtual columns. On TRUNCATE TABLE, an old .frm file from before MDEV-5800 may be used as the table schema. When the table is being re-created by InnoDB, the old schema must be used. That is, we may hide the existence of virtual columns from InnoDB. create_table_check_doc_id_col(): Remove the assertion that failed. This function can actually correctly deal with virtual columns that could have been created before MariaDB 10.2.2 introduced MDEV-5800. create_table_info_t::create_table_def(): Do not create metadata for virtual columns if the table definition was created before MariaDB 10.2.2.
-
- 18 Mar, 2019 5 commits
-
-
Alexander Barkov authored
-
Marko Mäkelä authored
os_file_fsync_posix(): If fsync() returns a fatal error, do include errno in the error message. In the future, we might handle fsync() or write or allocation failures on InnoDB data files a little more gracefully: flag the affected index or table as corrupted, and deny any subsequent writes to the table. If a write to the undo log or redo log fails, an alternative to killing the server could be to deny any writes to InnoDB tables until the server has been restarted.
-
Marko Mäkelä authored
-
Marko Mäkelä authored
-
sysprg authored
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
-
- 16 Mar, 2019 2 commits
-
-
Igor Babaev authored
In the function make_cond_for_table_from_pred a call of ix_fields() missed checking of the return code. As a result an extracted constant condition could be not well formed and this caused an assertion failure.
-
Jan Lindström authored
Idea is that many users do not install galera library and do not want to unnecessary run galera and wsrep suites. Furthermore, failures on these suites disturb development as buildbot shows red failing column and causes unnecessary work for those who do not care galera tests. There will be other way to run these suites on buildbot.
-
- 15 Mar, 2019 10 commits
-
-
Sergei Golubchik authored
Includes: MDEV-17302 Add support for ALTER USER command in prepared statement and MDEV-17673 main.cte_recursive fails in bb-10.4-ps branch in --ps Set correct SELECT_LEX linkage for recursive CTEs. Do not delegate this job to TABLE_LIST::set_as_with_table, because it is only run on prepare, while With_element::move_anchors_ahead is run both on prepare and execute (fix by Igor)
-
Sergei Golubchik authored
note: Inherit String from Sql_alloc, to get operators new and new[] in sync in rocksdb gcc was complaining that non-lvalue was cast to const.
-
Sergei Golubchik authored
-
Vladislav Vaintroub authored
-
Alexander Barkov authored
-
Marko Mäkelä authored
When there is a huge transaction in the undo log, the purge threads may get stuck in trx_purge_attach_undo_recs() for a long time, causing the server to hang on a normal shutdown (innodb_fast_shutdown>0). Apparently the innodb_purge_batch_size does not work correctly, or the n_pages_handled is not being incremented correctly. We do not fix that for now, but we will instead check if shutdown has been initiated, allowing the purge threads to shut down without delays.
-
Vladislav Vaintroub authored
-
Ian Gilfillan authored
-
Alexander Barkov authored
MDEV-16958 Assertion `field_length < 5' failed in Field_year::val_str or data corruption upon SELECT with UNION and aggregate functions
-
Igor Babaev authored
If an IN-subquery is used in a table-less select the current code should never consider it as candidate for semi-join optimizations. Yet the function check_and_do_in_subquery_rewrites() improperly checked the property "to be a table-less select". As a result such select in IN subquery was used in INSERT .. SELECT then the IN subquery by mistake was registered as a semi-join subquery and convert_subq_to_sj() was called for it. However the code of this function does not assume that the parent select of the subquery could be a table-less select.
-
- 14 Mar, 2019 5 commits
-
-
Sergei Golubchik authored
There were two newly enabled warnings: 1. cast for a function pointers. Affected sql_analyse.h, mi_write.c and ma_write.cc, mf_iocache-t.cc, mysqlbinlog.cc, encryption.cc, etc 2. memcpy/memset of nontrivial structures. Fixed as: * the warning disabled for InnoDB * TABLE, TABLE_SHARE, and TABLE_LIST got a new method reset() which does the bzero(), which is safe for these classes, but any other bzero() will still cause a warning * Table_scope_and_contents_source_st uses `TABLE_LIST *` (trivial) instead of `SQL_I_List<TABLE_LIST>` (not trivial) so it's safe to bzero now. * added casts in debug_sync.cc and sql_select.cc (for JOIN) * move assignment method for MDL_request instead of memcpy() * PARTIAL_INDEX_INTERSECT_INFO::init() instead of bzero() * remove constructor from READ_RECORD() to make it trivial * replace some memcpy() with c++ copy assignments
-
Alexander Barkov authored
-
Monty authored
The symptom of the bug was that one got the following in the aria recovery log: "Table 'xxx', id 57, has create_rename_lsn (1,0x12dee) more recent than LOGREC_FILE_ID's LSN (1,0x12dc4), ignoring open request" After this all future redo entries was marked with "For table of short id 57, table skipped, so skipping record" Analyze: When ending batch insert, create_rename_lsn for the table is updated to signal that earlier redo entries for the table can't be applied. The problem was that future redo entries was also ignored as redo code assumed they where for the old table. Fixed by calling translog_dessign_id, which causes future redo entries to be seen as belonging to the updated table.
-
Monty authored
-
Marko Mäkelä authored
On startup, if the InnoDB doublewrite buffer can be used to recover a corrupted page, raising an ERROR about a recoverable error seems inappropriate. Issue Note instead, and adjust tests accordingly. Also, correctly validate the tablespace ID in the files.
-