Remove some redundant declarations of global variables. These declarations
can refer to undefined type names, because they occur before any #include
statement for the type definitions. On GNU/Linux, uint and ulong seem to
be defined in <sys/types.h> due to _DEFAULT_SOURCE and __USE_MISC
becoming defined in <features.h>.
dict_index_t::db_trx_id(): Return the position of DB_TRX_ID.
Only valid for the clustered index.
dict_index_t::db_roll_ptr(): Return the position of DB_ROLL_PTR.
Only valid for the clustered index.
dict_index_get_sys_col_pos(): Remove. This was performing unnecessarily
complex computations, which only made sense for DB_ROW_ID, which would
exist either as the first field in the clustered index or as the last
field in a secondary index (only when a DB_ROW_ID column is materialised).
row_sel_store_row_id_to_prebuilt(): Remove, and replace with simpler code.
row_upd_index_entry_sys_field(): Remove.
btr_cur_log_sys(): Replaces row_upd_write_sys_vals_to_log().
btr_cur_write_sys(): Write DB_TRX_ID,DB_ROLL_PTR to a data tuple.
fts_get_max_doc_id(): Remove totally unnecessary call to rec_get_offsets().
In FTS_DOC_ID_INDEX, the FTS_DOC_ID is always stored in the first 8 bytes
of the record.
fts_get_doc_id_from_row(): Get the offsets from the caller.
row_ins_foreign_check_on_constraint(): Invoke rec_get_offsets()
for the call.
dict_index_t::reconstruct_fields(): Correctly permute the fields
of the columns. The code was totally wrong in MDEV-15562.
It would only work when columns are added last or dropped,
but not when columns are permuted.
row_ins_clust_index_entry_low(): Do not attempt to read an AUTO_INCREMENT
column value from a metadata record, because it does not make any sense.
Moreover, the field offset would be off by one in case the AUTO_INCREMENT
column is not part of the PRIMARY KEY, because the MDEV-15562 metadata
record would contain an extra field at index->first_user_field().
On MariaDB Server 10.3 after MDEV-11369, we would unnecessarily read
a dummy AUTO_INCREMENT value from the metadata record, but that value
would always be written as NULL or 0, so there is no problem.
THD::close_temporary_tables(): Revert the change.
ha_innobase::delete_table(): Move the work-around inside
a debug assertion, and check thd_kill_level() instead of thd_killed(),
because the latter would not hold for KILL_CONNECTION.
modified: ../sql-common/my_time.c
Moving the logic that mixes warnings of two kinds:
- those came from truncating garbage before the actual parsing of date/time
- those came during the actual parsing
from outside to inside of str_to_datetime_or_date_body().
This makes the caller code easier and removes some code duplication.
We'll be adding more parsing functions for time intervals soon,
so this change helps to avoid more duplicate code in the coming functions.
For prepare statemtent/stored procedures we rollback the items to original
ones after prepare execution in the function reinit_stmt_before_use.
This rollback is done for group by, order by clauses but is not done for
the window specification containing the order by and partition by clause of the
window function.
in 10.3, AWS encryption key was loaded during recovery, by the innodb purge
thread, therefore no note "loaded key" was written by the foreground
thread.
THD::close_temporary_tables(): Assign lex->sql_command so that
the debug assertion will not fail in ha_innobase::delete_table().
Alternatively, we could ensure that thd_killed() holds inside
ha_innobase::delete_table().
There should be no impact for the non-debug build. The thd_sql_command()
inside ha_innobase::delete_table() only affects the treatment of
persistent FOREIGN KEY metadata. There is no persistent metadata
nor foreign key constraints for temporary tables.
No test case was added, because the failure is nondeterministic.
The fix for "MDEV-17698 MEMORY engine performance regression"
previously fixed this problem.
- Adding the test for MDEV-17724
- Re-recording wrong results for tests:
* engines/iuds/r/insert_number
* engines/iuds/r/update_delete_number
which started to fail since MDEV-17698
sp_instr_cursor_copy_struct::exec_core() created TYPELIBs on a wrong mem_root,
the one which is initialized in sp_head::execute(), this code:
/* init per-instruction memroot */
init_sql_alloc(&execute_mem_root, "per_instruction_memroot",
MEM_ROOT_BLOCK_SIZE, 0, MYF(0));
This memory root cleans up after every sp_instr_xxx executed, so later
sp_instr_cfetch::execute() tried to use already freed and trashed memory.
Changing sp_instr_cursor_copy_struct::exec_core() to call tmp.export_structure()
inside this block (not outside of it):
thd->set_n_backup_active_arena(thd->spcont->callers_arena, ¤t_arena);
...
thd->restore_active_arena(thd->spcont->callers_arena, ¤t_arena);
So now TYPELIBs created by sp_instr_cursor_copy_struct::exec_core() are
still available and valid when sp_instr_cfetch::execute() is called.
They are freed at the end of dispatch_command() corresponding to
the "CALL p1" statement.
- clean up DEFAULT() to work only with default value and correctly print
itself.
- fix of DBUG_ASSERT about fields read/write
- fix of field marking for write based really on the thd->mark_used_columns flag
