- 08 Oct, 2018 1 commit
-
-
Alexander Barkov authored
Problems: Functions LEAST() and GREATEST() in TIME context, as well as functions TIMESTAMP(a,b) and ADDTIME(a,b), returned confusing results when the input TIME-alike value in a number or in a string was out of the TIME supported range. In case of TIMESTAMP(a,b) and ADDTIME(a,b), the second argument value could get extra unexpected digits. For example, in: ADDTIME('2001-01-01 00:00:00', 10000000) or ADDTIME('2001-01-01 00:00:00', '1000:00:00') the second argument was converted to '838:59:59.999999' with six fractional digits, which contradicted "decimals" previously set to 0 in fix_length_and_dec(). These unexpected fractional digits led to confusing function results. Changes: 1. GREATEST(), LEAST() - fixing Item_func_min_max::get_time_native() to respect "decimals" set by fix_length_and_dec(). If a value of some numeric or string time-alike argument goes outside of the TIME range and gets limited to '838:59:59.999999', it's now right-truncated to the correct fractional precision. - fixing, Type_handler_temporal_result::Item_func_min_max_fix_attributes() to take into account arguments' time_precision() or datetime_precision(), rather than rely on "decimals" calculated by the generic implementation in Type_handler::Item_func_min_max_fix_attributes(). This makes GREATEST() and LEAST() return better data types, with the same fractional precision with what TIMESTAMP(a,b) and ADDTIME(a,b) return for the same arguments, and with DATE(a) and TIMESTAMP(a). 2. Item_func_add_time and Item_func_timestamp It was semantically wrong to apply the limit of the TIME data type to the argument "b", which plays the role of "INTERVAL DAY TO SECOND" here. Changing the code to fetch the argument "b" as INTERVAL rather than as TIME. The low level routine calc_time_diff() now gets the interval value without limiting to '838:59:59.999999', so in these examples: ADDTIME('2001-01-01 00:00:00', 10000000) ADDTIME('2001-01-01 00:00:00', '1000:00:00') calc_time_diff() gets '1000:00:00' as is. The SQL function result now gets limited to the supported result data type range (datetime or time) inside calc_time_diff(), which now calculates the return value using the real fractional digits that came directly from the arguments (without the effect of limiting to the TIME range), so the result does not have any unexpected fractional digits any more. Detailed changes in TIMESTAMP() and ADDTIME(): - Adding a new class Interval_DDhhmmssff. It's similar to Time, but: * does not try to parse datetime format, as it's not needed for functions TIMESTAMP() and ADDTIME(). * does not cut values to '838:59:59.999999' The maximum supported Interval_DDhhmmssff's hard limit is 'UINT_MAX32:59:59.999999'. The maximum used soft limit is: - '87649415:59:59.999999' (in 'hh:mm:ss.ff' format) - '3652058 23:59:59.999999' (in 'DD hh:mm:ss.ff' format) which is a difference between: - TIMESTAMP'0001-01-01 00:00:00' and - TIMESTAMP'9999-12-31 23:59:59.999999' (the minimum datetime that supports arithmetic, and the maximum possible datetime value). - Fixing get_date() methods in the classes related to functions ADDTIME(a,b) and TIMESTAMP(a,b) to use the new class Interval_DDhhmmssff for fetching data from the second argument, instead of get_date(). - Fixing fix_length_and_dec() methods in the classes related to functions ADDTIME(a,b) and TIMESTAMP(a,b) to use Interval_DDhhmmssff::fsp(item) instead of item->time_precision() to get the fractional precision of the second argument correctly. - Splitting the low level function str_to_time() into smaller pieces to reuse the code. Adding a new function str_to_DDhhmmssff(), to parse "INTERVAL DAY TO SECOND" values. After these changes, functions TIMESTAMP() and ADDTIME() return much more predictable results, in terms of fractional digits, and in terms of the overall result. The full ranges of DATETIME and TIME values are now covered by TIMESTAMP() and ADDTIME(), so the following can now be calculated: SELECT ADDTIME(TIMESTAMP'0001-01-01 00:00:00', '87649415:59:59.999999'); -> '9999-12-31 23:59:59.999999' SELECT TIMESTAMP(DATE'0001-01-01', '87649415:59:59.999999') -> '9999-12-31 23:59:59.999999' SELECT ADDTIME(TIME'-838:59:59.999999', '1677:59:59.999998'); -> '838:59:59.999999'
-
- 07 Oct, 2018 1 commit
-
-
Igor Babaev authored
This was a bug in the code of MDEV-12387 "Push conditions into materialized subqueries". The bug manifested itself in rather rare situations. An affected query must contain IN subquery predicate whose left operand was an outer field of a mergeable derived table or view and right operand was a materialized subquery. The erroneous code in fact stripped off the Item_direct_ref wrapper from the left operand of the IN subquery predicate when building equalities produced by the conversion of the predicate into a semi-join. As a result the left operand was not considered as an outer reference anymore and used_tables() was calculated incorrectly. This caused a crash in the function optimize_keyuse().
-
- 05 Oct, 2018 4 commits
-
-
Vladislav Vaintroub authored
-
Vladislav Vaintroub authored
- remove function prototype for shared memory (no more used), and VIO members that are unused - Do not call DisconnectNamedPipe on pipe handle. CloseHandle() is enough.
-
Vladislav Vaintroub authored
Remove threads that are doing nothing but wait - main thread now handles the connections (if threadpool is used, also threadpool threads would wait for connections) - thread for socket and pipe connections are removed - shutdown thread is now removed, we wait for shutdown notification in main thread as well - kill_server() is also called inside the main thread, after connection loop finished.
-
Marko Mäkelä authored
-
- 04 Oct, 2018 2 commits
-
-
Marko Mäkelä authored
btr_cur_instant_root_init(): Check the "infimum" and "supremum" record strings already here, and not later in btr_cur_instant_root_init(). In this way, we can properly reject files from later versions where instant ALTER TABLE could support further operations that change the format of InnoDB clustered indexes.
-
Marko Mäkelä authored
-
- 03 Oct, 2018 2 commits
-
-
Marko Mäkelä authored
Because changes of the FIL_PAGE_TYPE or PAGE_INSTANT in the root page are not undo-logged, it is possible that the fields suggest that instant ADD COLUMN is in effect, even though no metadata record exists. If the fields are set, proceed to fetch the metadata record. If the metadata record does not exist, return success if !index->is_instant(). Also, check that the "infimum" and "supremum" records carry the strings in the root page. In a later format that supports instant DROP COLUMN, we will have to store more information in the root page, so that index->n_core_null_bytes can be determined accurately.
-
Marko Mäkelä authored
btr_cur_instant_init_low(): If columns were instantly added and dropped, then index->is_instant() might not hold even though the root page type was FIL_PAGE_TYPE_INSTANT. MariaDB 10.3 must refuse to open such files, because instant DROP COLUMN is not supported. Also, refuse to open the table if the metadata record has wrong info OR status bits. Previously, we only refused to open if both bits were wrong.
-
- 02 Oct, 2018 3 commits
-
-
Jan Lindström authored
MDEV-16211 Contents of transaction_registry should not be replicated by Galera
-
Elena Stepanova authored
Addition based on Travis results
-
Sergey Vojtovich authored
truncating a temporary table TRUNCATE expects only one TABLE instance (which is used by TRUNCATE itself) to be open. However this requirement wasn't enforced after "MDEV-5535: Cannot reopen temporary table". Fixed by closing unused table instances before performing TRUNCATE.
-
- 01 Oct, 2018 6 commits
-
-
Elena Stepanova authored
-
Eugene Kosov authored
Patch fixes two bugs: 1) BEGIN_TIMESTAMP of MYSQL.TRANSACTION_REGISTY is '0-0-0' on replication record insertion 2) BEGIN_TIMESTAMP equals COMMMIT_TIMESTAMP in MYSQL.TRANSACTION_REGISTRY Fixed by calling THD::set_time() at appropriate places
-
Alexander Barkov authored
-
Alexander Barkov authored
A cleanup for MDEV-17317 Add THD* parameter into Item::get_date() and stricter data type control to "fuzzydate" Fixing C++ function check_date() to get the "fuzzydate" as date_mode_t rather than ulonglong, so conversion from date_time_t to ulonglong is now done inside C++ check_date(), and no conversion is needed in the callers' code. As an additional safety, modified the code not to pass TIME_FUZZY_DATE to the low level C functions: - check_date() - str_to_datetime() - str_to_time() - number_to_datetime() because TIME_FUZZY_DATE is known only on the C++ level, C functions do not know it. Soon we'll be adding more flags into the C++ level (i.e. to date_time_t), e.g. for rounding. It's a good idea to prevent passing C++ specific flags into pure C routines before this change. Asserts were added into the affected C functions to verify that the caller passed only known C level flags.
-
Sergei Golubchik authored
-
Marko Mäkelä authored
-
- 30 Sep, 2018 3 commits
-
-
Marko Mäkelä authored
rec_offs_nth_extern_old() was introduced in commit a4948daf and never used.
-
Marko Mäkelä authored
-
Alexander Barkov authored
Also fixes: MDEV-17330 Wrong result for 0 + LEAST(TIME'-10:00:00',TIME'10:00:00') Problems: 1. These methods did not take into account the current session date flags and passed date_mode_t(0) to func->get_date(): Type_handler_temporal_result::Item_func_min_max_val_real Type_handler_temporal_result::Item_func_min_max_val_int Type_handler_temporal_result::Item_func_min_max_val_decimal Fixing to pass sql_mode_for_dates(thd) instead of date_mode_t(0). Note, sql_mode_for_dates(thd) is only needed for DATE/DATETIME data types. It is not needed for TIME. So splitting value methods Type_handler_temporal_result::Item_func_min_max_xxx into individual implementations for Type_handler_{time|date|datetime|timestamp}_common and, instead of calling get_date(), reusing inside classes Time(), Date(), Datetime() and their methods to_longlong(). sql_mode_for_dates(thd) is automatically passed to get_date() inside Date() and Datetime() constructors. The switch to classes also fixed the problem reported in MDEV-17330. Type_handler_temporal_result::Item_func_min_max_val_int() used to call TIME_to_ulonglong(), which was not correct for TIME. Changing the code to use Time().to_longlong() solved this. 2. Type_handler_temporal_result::Item_func_min_max_get_date also did not take into account the current session date flags in case of conversion from DATE/DATETIME to time and passed date_mode_t(0) to get_date_native(). Fixing to pass sql_mode_for_dates(thd) in case of conversion from DATE/DATETIME to TIME.
-
- 29 Sep, 2018 1 commit
-
-
Alexander Barkov authored
-
- 28 Sep, 2018 6 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
Alexander Barkov authored
-
- 27 Sep, 2018 1 commit
-
-
Alexander Barkov authored
MDEV-15406 NO_ZERO_IN_DATE erroneously affects how CAST(AS DATE) warns about fractional digit truncation
-
- 26 Sep, 2018 2 commits
-
-
Alexander Barkov authored
MDEV-17219 Assertion `!t->fraction_remainder(decimals())' failed in Field_time::store_TIME_with_warning
-
Marko Mäkelä authored
-
- 25 Sep, 2018 1 commit
-
-
Alexander Barkov authored
-
- 24 Sep, 2018 2 commits
-
-
Sergei Golubchik authored
-
Sergei Golubchik authored
-
- 23 Sep, 2018 5 commits
-
-
Sergei Golubchik authored
storage/rocksdb/rdb_datadic.cc: In member function 'int myrocks::Rdb_key_def::unpack_integer(myrocks::Rdb_field_packing*, Field*, uchar*, myrocks::Rdb_string_reader*, myrocks::Rdb_string_reader*) const' storage/rocksdb/rdb_datadic.cc:1781:1: internal compiler error: Segmentation fault } on ppc64le, ubuntu bionic gcc 7.3.0 and debian stretch gcc 6.3.0 The error happens with -ftree-loop-vectorize when trying to vectorize a particular loop (see Rdb_key_def::unpack_integer()) Compiler gets confused by __attribute__((optimize("O0")) that comes from ha_rocksdb_proto.h. The intention of this __attribute__ was to prevent function from being inlined (see ha_rocksdb.cc). Let's use a more specific attribute that prevents inlining but does not confuse loop vectorizer.
-
Sergei Golubchik authored
-
Jan Lindström authored
-
Sergei Petrunia authored
An error in "group commit with MariaDB's binlog" code: we would flush the WAL even when the transaction did not do any writes (and so the logic in myrocks::Rdb_transaction::commit caused it to rollback).
-
Jan Lindström authored
-