Side effect: the second debug Note in cache_temporal_4265.result disappeared.
Before this change:
- During JOIN::cache_const_exprs(),
Item::get_cache() for Item_date_add_interval() was called.
The data type for date_add('2001-01-01',interval 5 day) is VARCHAR,
because the first argument is VARCHAR (not temporal).
Item_get_cache() created Item_cache_str('2001-01-06').
- During evaluate_join_record(), get_datetime_value() was called,
which called Item::get_date() for Item_cache_str('2001-01-06').
This gave the second Note. Then, get_datetime_value() created
a new cache, now Item_cache_temporal for '2001-01-06', so not
further str_to_datetime() happened.
After this change:
- During tem_bool_rowready_func2::fix_length_and_dec(),
Arg_comparator::set_cmp_func_datetime() is called,
which immediately creates an instance of Item_cache_date for
the result of date_add('2001-01-01',interval 5 day).
So later no str_to_datetime happens any more,
neither during JOIN::cache_const_exprs(),
nor during evaluate_join_record().
This happens when doing NEXT VALUE for a temporary table
Fixed by giving ER_NOT_SEQUENCE when trying to use normal temporary table with
sequence functions
Signed-off-by: Monty <monty@mariadb.org>
This happened when trying to do delete a sequence hidden by a temporary
table.
Fixed by ignoring non-sequence temporary tables when trying to drop
sequences.
Signed-off-by: Monty <monty@mariadb.org>
Fixes two issues:
- Update assert in open_and_process_tables to handle sequences
- Removed not needed and conflicting mdl_context.release_transactional_locks
in sql_sequence.cc. The MDL lock is released at end of
mysql_execute_command().
Signed-off-by: Monty <monty@mariadb.org>
This happened when trying to PARTITION a SEQUENCE table
Problem was that wrong function was used to get engine name
Signed-off-by: Monty <monty@mariadb.org>
Fixing mysql_execute_command() and store_schema_proc() not to use
stored object type codes TYPE_ENUM_PROCEDURE and TYPE_ENUM_FUNCTION.
Using pointers to Sp_handler instead, to make the code symmetric across
existing (function,procedure) and future (e.g package) SP object types.
The problem was that the code in replication didn't distinguish between a
setval() failing because the stored sequence number was bigger than the
current (should have been ignored) and a failure from the storage engine.
- Renaming sp_rcontext::sp to sp_rcontext:m_sp for consistency
with other sp_rcontext_members, and for consistency with the
same purpose member Item_sp_variable::m_sp.
- Passing a "const sp_head*" pointer to sp_rcontext::sp_rcontext()
and to sp_rcontext::create().
Initializing sp_rcontext::m_sp right in the constructor
instead of having a separate initialization after "new sp_rcontext"
or sp_rcontext::create().
- Adding the "const" qualifier to sp_rcontext::m_sp and Item_sp_variable::m_sp
MySQL 5.7 added code to push down the LIMIT to fulltext search
in InnoDB:
commit 2cd0ebf97e1b265e2282d7ceb5d8dfb663ffc48f
Author: Thirunarayanan Balathandayuthapani <thirunarayanan.balathandayuth@oracle.com>
Date: Fri May 27 13:49:28 2016 +0530
Bug #22709692 FTS QUERY EXCEEDS RESULT CACHE LIMIT
The code was disabled when MySQL 5.7.9 was merged to MariaDB 10.2.2.
We shall remove the disabled code and unnecessary variables.
This was a false alarm in a debug check that was introduced in
commit 48192f963a which was a
10.2 code refactoring in preparation for
MDEV-11369 (instant ADD COLUMN) in 10.3.2. The code refactoring
only affected debug builds.
InnoDB B-tree record locks are only supposed to exist on leaf page
records. An assertion failed, because the debug function lock_validate()
was invoking lock_rec_block_validate() on a page for which there were
no locks set in the record lock bitmap. This could happen on a page split.
Especially when the index size grows from a single page to multiple pages,
the root page would transform from a leaf node into an internal node,
and its record lock bitmap would be emptied.
lock_validate(): Skip empty lock bitmaps.
Problem was that we could take page latches on different
order than wat is entitled with SX-lock. To follow the
latching order defined in WL#6326, acquire index->lock X-latch.
This entitles us to acquire page latches in any order for the index.
btr0btr.cc
Document latch rules before and after MariaDB 10.2.2
sync0rw.cc
Document latch compatibility rules better.
btr_defragment_merge_pages
Fix parameter value.
btr_defragment_thread
Acquire X-lock to dict_index_t::lock before restoring
cursor position and continuing defragmentation.
ha_innobase::optimize
Restore defragment feature.
Testing
Add GIS-index and FT-index to table being defragmented.
Defragmentation is not done to GIS-indexes and FT auxiliary
tables.
A reference to a CTE may occur not in the master of the CTE
specification. In this case if the reference to the CTE is
the first one the specification should be detached from its
master and attached to the referencing select.
Also fixed the TYPE column in the lines of the EXPLAIN output
created for CTE tables.
in 10.1 innodb was basically ignoring virtual columns. In particular,
information about them was not stored in system tables. To make 10.1
table usable in 10.2 it needs to be rebuilt to have virtual colunm
metadata properly recreated.
See also a followup:
MDEV-14046 Allow ALGORITHM=INPLACE for 10.1 tables that contain virtual columns
The fix 716f97e271
was inadvertently reverted in
commit 2e814d4702
"Merge InnoDB 5.7 from mysql-5.7.9".
Reapply the fix, because the test of the bug would fail
after merging MDEV-13838, which replaced an earlier incorrect
bug fix with a correct one.
Mariabackup 10.2.7 would delete the redo log files after a successful
--prepare operation. If the user is manually copying the prepared files
instead of using the --copy-back option, it could happen that some old
redo log file would be preserved in the restored location. These old
redo log files could cause corruption of the restored data files when
the server is started up.
We prevent this scenario by creating a "poisoned" redo log file
ib_logfile0 at the end of the --prepare step. The poisoning consists
of simply truncating the file to an empty file. InnoDB will refuse
to start up on an empty redo log file.
copy_back(): Delete all redo log files in the target if the source
file ib_logfile0 is empty. (Previously we did this if the source
file is missing.)
SRV_OPERATION_RESTORE_EXPORT: A new variant of SRV_OPERATION_RESTORE
when the --export option is specified. In this mode, we will keep
deleting all redo log files, instead of truncating the first one.
delete_log_files(): Add a parameter for the first file to delete,
to be passed as 0 or 1.
innobase_start_or_create_for_mysql(): In mariabackup --prepare,
tolerate an empty ib_logfile0 file. Otherwise, require the first
redo log file to be longer than 4 blocks (2048 bytes). Unless
--export was specified, truncate the first log file at the
end of --prepare.
Use GetFileInformationByHandleEx with FileAttributeTagInfo to query whether
the file is sparse. This saves 1 syscall, as GetFileInformationByHandle()
would additionally query volume info.
Try to fix fragmentation (unsparse files), for pre-existing
installations.
Unsparse the innodb file, when it needs to be extended, unless compression
is used. For Win7/2008R2 unsparse does not work (as documented in MSDN),
therefore for sparse files in older Windows, file extension will be done
via writing zeroes at the end of file.
The last parameter to this function is now,"bool is_sparse", like in 10.1
rather than the unused/useless "bool is_readonly", merged from MySQL 5.7
Like in 10.1, this function now supports sparse files, and efficient
platform specific mechanisms for file extension
os_file_set_size() is now consistenly used in all places where
innodb files are extended.
galera_events test shows a regression with the original fix for MW-416
Reason was that Events::drop_event() can be called also from inside event
execution, and there we have a speacial treatment for event, which executes
"DROP EVENT" statement, and runs TOI replication inside the event processing body.
This resulted in executing WSREP_TO_ISOLATION two times for such DROP EVENT statement.
Fix is to call WSREP_TO_ISOLATION_BEGIN only in Events::drop_event()
Changed return code for replicatio error to TRUE.
This is aligned with native mysql convention to return TRUE (defined to 1) or FALSE (defined to 0) from a bool function.
This is wrong, but follows the mysql conventiosn, at least...
Moved TOI replication to happen after ACL checking for commands:
SQLCOM_CREATE_EVENT
SQLCOM_ALTER_EVENT
SQLCOM_DROP_EVENT
SQLCOM_CREATE_VIEW
SQLCOM_CREATE_TRIGGER
SQLCOM_DROP_TRIGGER
SQLCOM_INSTALL_PLUGIN
SQLCOM_UNINSTALL_PLUGIN
MariaDB 10.1 introduced non-indexed virtual columns for InnoDB tables.
When MySQL 5.7 introduced virtual columns in InnoDB tables, it also
introduced the table SYS_VIRTUAL that stores metadata on virtual
columns. This table does not initially exist in data files that were
imported from 10.1. So, we do not always have virtual column metadata
inside InnoDB.
dict_index_contains_col_or_prefix(): In the clustered index records,
all non-virtual columns are present and no virtual columns are present.
ha_innobase::build_template(): In the clustered index, do not
include virtual columns in the query template. The SQL layer is
supposed to compute the virtual column values when needed.
When btr_create() invokes btr_free_root() after running out of space,
fseg_create() would have acquired an SX-latch on the root page, not
an X-latch. Relax the debug assertion in btr_free_root() accordingly.
(In this case, SX-latch and X-latch are equivalent. During the CREATE
operation there should be MDL_EXCLUSIVE and dict_operation_lock X-latch
preventing concurrent access to the index. Normally the purpose of the
SX-latch is to allow concurrent reads of the root page while certain
fields in the root page are updated in place.)