Rollback attempted to dereference DB_ROLL_PTR=0, which cannot possibly
be a valid undo log pointer. A safe canonical value would be
roll_ptr_t(1) << ROLL_PTR_INSERT_FLAG_POS
which is what was chosen in MDEV-12288.
This bug was reproduced in 10.3 only. Potentially, the problem could
have been introduced by MDEV-11415, which suppresses undo logging for
ALGORITHM=COPY operations. In those operations, we should actually
have written the safe value of DB_ROLL_PTR instead of writing 0.
However, the test in commit 5421e3aee7
demonstrates that access to the rebuilt table by earlier-started
transactions should actually have been refused with ER_TABLE_DEF_CHANGED.
btr_cur_ins_lock_and_undo(): When undo logging is disabled, use the
safe value of DB_ROLL_PTR.
btr_cur_optimistic_insert(): Validate the DB_TRX_ID,DB_ROLL_PTR before
inserting into a clustered index leaf page.
ins_node_t::sys_buf[]: Replaces row_id_buf and trx_id_buf and some
heap usage.
row_ins_alloc_sys_fields(): Initialize ins_node_t::sys_buf[].
trx_undo_page_report_modify(): Assert that the DB_ROLL_PTR is not 0.
trx_undo_get_undo_rec_low(): Assert that the roll_ptr is valid before
trying to dereference it.
dict_index_t::is_primary(): Check if the index is the primary key.
PageConverter::adjust_cluster_record(): Instead of writing
the invalid value DB_ROLL_PTR=0, write a value that indicates
a fresh insert, that is, prevents the DB_ROLL_PTR from being
dereferenced in any circumstances.
It can be argued that IMPORT TABLESPACE should actually
update the dict_index_t::trx_id to prevent older transactions
from accessing the table, similar to what I did on table
rebuild in MySQL 5.6.6 in
03f81a55f2
If the CRYPTO_set_mem_functions fails just return success
from check_openssl_compatibility. The only case where
CRYPTO_set_mem_functions fails is the allow_customize==0 (aka FIPS
mode). The check_openssl_compatibility isn't able to complete unless
this function returns success.
ref: https://github.com/openssl/openssl/blob/OpenSSL_1_1_0g/crypto/mem.c#L34
MDEV-14222 Unnecessary 'cascade' memory allocation for every updated row
when there is no FOREIGN KEY
This reverts the MySQL 5.7.2 change
377774689b
which introduced these problems. MariaDB 10.2.2 inherited these problems
in commit 2e814d4702.
The FOREIGN KEY CASCADE and SET NULL operations implemented as
procedural recursion are consuming more than 8 kilobytes of stack
(9 stack frames) per iteration in a non-debug GNU/Linux AMD64 build.
This is why we need to limit the maximum recursion depth to 15 steps
instead of the 255 that it used to be in MySQL 5.7 and MariaDB 10.2.
A corresponding change was made in MySQL 5.7.21 in
7b26dc98a6
This corruption was introduced in MDEV-13331. It would have been caught
by the MySQL 5.7 test innodb.update-cascade which MariaDB was missing
until now.
row_ins_check_foreign_constraint(): Never replace err == DB_LOCK_WAIT
with other values than DB_LOCK_WAIT_TIMEOUT.
row_ins_cascade_calc_update_vec(): Remove the output parameter
fts_col_affected, and instead return whether any fulltext index
is affected by the cascade operation.
row_ins_foreign_check_on_constraint(): Narrow the scope of some
variables.
ib_dec_in_dtor: Remove.
does not return error
Corrected the code of st_select_lex::find_table_def_in_with_clauses() for
a proper identification of CTE references used in embedded CTEs.
When identifying a table name the following should be taken into account:
a CTE name cannot be qualified with a database name, otherwise the table
name is considered as the name of a non-CTE table.
in gcc `-Wno-unsupported-something` will not be an error or even a warning,
so cmake will think the flag is supported. But if there's any other
warning during compilation, for any reason, unknown option will
be a warning too. Or an error when -Werror, even if that "other warning"
would not be an error on itself.
So we need to detect whether `-Wno-unsupported-something` is *really*
supported. Luckily, `-Wunsupported-something` will always fail with an
error.
So, whenever there's a need to detect if -Wno-something is supported,
test -Wsomething instead.
Problem was that wrong error message was returned when insert
returned FK-error and there was no duplicate key to process.
row_ins
If error from insert was DB_NO_REFERENCED_ROW and there was
no duplicate key we should ignore ON DUPLICATE KEY UPDATE
and return original error message.
Suppress some messages that are emitted rarely
(when the FIL_PAGE_FILE_FLUSH_LSN of the first page of ibdata1
does not match the latest redo log checkpoint).
Previously, the function could theoretically return an uninitialized
value if the system tablespace contained no data files. It should be
impossible for InnoDB to start up in such scenario.
Two follow-up tasks were filed for MySQL 5.7.21 changes that
were not applied here:
MDEV-15179 performance_schema.file_instances does not reflect RENAME TABLE
MDEV-14222 Unnecessary 'cascade' memory allocation for every updated
row when there is no FOREIGN KEY
The merge omitted some InnoDB and XtraDB conflict resolutions,
most notably, failing to merge the fix of MDEV-12173.
ibuf_merge_or_delete_for_page(), lock_rec_block_validate():
Invoke fil_space_acquire_silent() instead of fil_space_acquire().
This fixes MDEV-12173.
wsrep_debug, wsrep_trx_is_aborting(): Removed unused declarations.
_fil_io(): Remove. Instead, declare default parameters for the XtraDB
fil_io().
buf_read_page_low(): Declare default parameters, and clean up some
callers.
os_aio(): Correct the macro that is defined when !UNIV_PFS_IO.
Remove a test that does not apply to MariaDB
In MariaDB, there are no high-priority transactions (no tx_priority).
This should also mean that all references to TRX_STATE_FORCED_ROLLBACK
are dead code.
Bug#23590280 NO WARNING WHEN REDUCING INNODB_BUFFER_POOL_SIZE
INSIZE (sic) THE FIRST CHUNK
innodb_buffer_pool_size_validate(): Issue a warning if the
requested innodb_buffer_pool_size is less than
innodb_buffer_pool_chunk_size, because we cannot shrink individual
chunks.
