Commit graph

1104 commits

Author SHA1 Message Date
Sergei Golubchik
5e0038b376 cleanup: remove Regexp_processor_pcre::m_subpatterns_needed
it's unused now.
2017-05-29 21:07:54 +02:00
Marko Mäkelä
13a350ac29 Merge 10.0 into 10.1 2017-05-19 12:29:37 +03:00
Sergei Golubchik
52aa200919 MDEV-12420 max_recursive_iterations did not prevent a stack-overflow and segfault
post-review fixes
* move pcre-specific variable out of mysys
* don't use current_thd
* move a commonly used macro to my_sys.h
* remove new sysvar
2017-05-15 22:23:10 +02:00
Daniel Black
602b5e4c49 WIP: global readonly variable pcre_frame_size 2017-05-15 22:23:10 +02:00
Daniel Black
d672f88ef7 MDEV-12420: PCRE stack overflow
It was possible to construct a PCRE expression that exceeded the stack.
resulting in a crash:

With fix:

MariaDB [(none)]> SELECT 1
    -> FROM dual
    -> WHERE ('Alpha,Bravo,Charlie,Delta,Echo,Foxtrot,StrataCentral,Golf,Hotel,India,Juliet,Kilo,Lima,Mike,StrataL3,November,Oscar,StrataL2,Sand,P3,P4SwitchTest,Arsys,Poppa,ExtensionMgr,Arp,Quebec,Romeo,StrataApiV2,PtReyes,Sierra,SandAcl,Arrow,Artools,BridgeTest,Tango,SandT,PAlaska,Namespace,Agent,Qos,PatchPanel,ProjectReport,Ark,Gimp,Agent,SliceAgent,Arnet,Bgp,Ale,Tommy,Central,AsicPktTestLib,Hsc,SandL3,Abuild,Pca9555,Standby,ControllerDut,CalSys,SandLib,Sb820,PointV2,BfnLib,Evpn,BfnSdk,Sflow,ManagementActive,AutoTest,GatedTest,Bgp,Sand,xinetd,BfnAgentLib,bf-utils,Hello,BfnState,Eos,Artest,Qos,Scd,ThermoMgr,Uniform,EosUtils,Eb,FanController,Central,BfnL3,BfnL2,tcp_wrappers,Victor,Environment,Route,Failover,Whiskey,Xray,Gimp,BfnFixed,Strata,SoCal,XApi,Msrp,XpProfile,tcpdump,PatchPanel,ArosTest,FhTest,Arbus,XpAcl,MacConc,XpApi,telnet,QosTest,Alpha2,BfnVlan,Stp,VxlanControllerTest,MplsAgent,Bravo2,Lanz,BfnMbb,Intf,XCtrl,Unicast,SandTunnel,L3Unicast,Ipsec,MplsTest,Rsvp,EthIntf,StageMgr,Sol,MplsUtils,Nat,Ira,P4NamespaceDut,Counters,Charlie2,Aqlc,Mlag,Power,OpenFlow,Lag,RestApi,BfdTest,strongs,Sfa,CEosUtils,Adt746,MaintenanceMode,MlagDut,EosImage,IpEth,MultiProtocol,Launcher,Max3179,Snmp,Acl,IpEthTest,PhyEee,bf-syslibs,tacc,XpL2,p4-ar-switch,p4-bf-switch,LdpTest,BfnPhy,Mirroring,Phy6,Ptp'
    ->
    -> REGEXP '^((?!\b(Strata|StrataApi|StrataApiV2)\b).)*$');
Empty set, 1 warning (0.00 sec)

MariaDB [(none)]> show warnings;
+---------+------+---------------------------------------------------------+
| Level   | Code | Message                                                 |
+---------+------+---------------------------------------------------------+
| Warning | 1139 | Got error 'pcre_exec: Internal error (-21)' from regexp |
+---------+------+---------------------------------------------------------+
2017-05-15 22:23:10 +02:00
Marko Mäkelä
ad0c218a44 Merge 10.0 into 10.1
Also, implement MDEV-11027 a little differently from 5.5 and 10.0:

recv_apply_hashed_log_recs(): Change the return type back to void
(DB_SUCCESS was always returned).

Report progress also via systemd using sd_notifyf().
2017-03-09 08:53:08 +02:00
Sergei Golubchik
f7d030489d Merge branch '10.0' into 10.1 2017-01-17 20:17:35 +01:00
Sergei Golubchik
6728aae3b3 Merge branch '5.5' into 10.0 2017-01-17 16:22:25 +01:00
Sergei Golubchik
67e2028161 MDEV-9690 concurrent queries with virtual columns crash in temporal code
Item_func_le included Arg_comparator. Arg_comparator remembered
the current_thd during fix_fields and used that value during
execution to allocate Item_cache in get_datetime_value().
But for vcols fix_fields and val_int can happen in different threads.

Same bug for Item_func_in using in_datetime or cmp_item_datetime,
both also remembered current_thd at fix_fields() to use it later
for get_datetime_value().

As a fix, these objects no longer remember the current_thd,
and get_datetime_value() uses current_thd at run time. This
should not increase the number of current_thd calls much, as
Item_cache is created only once anyway.
2017-01-15 00:11:02 +01:00
Sergei Golubchik
2f20d297f8 Merge branch '10.0' into 10.1 2016-12-11 09:53:42 +01:00
Igor Babaev
748d993cca Fixed bug mdev-11364.
The function Item_func_isnull::update_used_tables() must
handle the case when the predicate is over not nullable
column in a special way.
This is actually a bug of MariaDB 5.3/5.5, but it's probably
hard to demonstrate that it can cause problems there.
2016-11-29 11:29:07 -08:00
Alexander Barkov
f0d8a4d29e MDEV-11219 main.null fails in buldbot and outside with ps-protocol 2016-11-03 22:02:24 +04:00
Alexander Barkov
c18054deb2 MDEV-10347 mysqld got signal 11 2016-11-02 08:20:15 +04:00
Alexander Barkov
3ccf8218bc Partial backporting of 7b50447aa6
(MDEV-9407, MDEV-9408) from 10.1

Needed to fix MDEV-10317 easier.
2016-07-03 11:20:46 +04:00
Alexander Barkov
a87507eec3 MDEV-9712 Performance degradation of nested NULLIF
10.1 introduced a problem:
Execution time for various recursive stages
(walk, update_used_table, and propagate_equal_fields)
in NULLIF is O(recursion_level^2), because complexity is
doubled on every recursion level when we copy args[0] to args[2].

This change fixes to avoid unnecessary recursion in:
- Item_func_nullif::walk
- Item_func_nullif::update_used_tables
- Item_func_nullif::propagate_equal_fields
when possible.
2016-05-05 15:39:04 +04:00
Sergei Golubchik
872649c7ba Merge branch '5.5' into 10.0 2016-04-26 23:05:26 +02:00
Alexander Barkov
9a987142f9 MDEV-9745 Crash with CASE WHEN TRUE THEN COALESCE(CAST(NULL AS UNSIGNED)) ELSE 4 END
This is a backport of the patch for MDEV-9653 (fixed earlier in 10.1.13).

The code in Item_func_case::fix_length_and_dec() did not
calculate max_length and decimals properly.

In case of any numeric result (DECIMAL, REAL, INT) a generic method
Item_func_case::agg_num_lengths() was called, which could erroneously result
into a DECIMAL item with max_length==0 and decimals==0, so the constructor of
Field_new_decimals tried to create a field of DECIMAL(0,0) type,
which caused a crash.

Unlike Item_func_case, the code responsible for merging attributes in
Item_func_coalesce::fix_length_and_dec() works fine: it has specific execution
branches for all distinct numeric types and correctly creates a DECIMAL(1,0)
column instead of DECIMAL(0,0) for the same set of arguments.

The fix does the following:
- Moves the attribute merging code from Item_func_coalesce::fix_length_and_dec()
  to a new method Item_func_hybrid_result_type::fix_attributes()
- Removes the wrong code from Item_func_case::fix_length_and_dec()
  and reuses fix_attributes() in both Item_func_coalesce::fix_length_and_dec()
  and Item_func_case::fix_length_and_dec()
- Fixes count_real_length() and count_decimal_length() to get an array
  of Items as an argument, instead of using Item::args directly.
  This is needed for Item_func_case::fix_length_and_dec().
- Moves methods Item_func::count_xxx_length() from "public" to "protected".
- Removes Item_func_case::agg_num_length(), as it's not used any more.
- Additionally removes Item_func_case::agg_str_length(),
  as it also was not used (dead code).
2016-04-20 08:53:30 +04:00
Alexander Barkov
9476854211 MDEV-9369 IN operator with ( num, NULL ) gives inconsistent result
Based on this commit into MySQL-5.7:
> commit 8e51b845aafc8b4cdebd763c8aebda262ac2d4cd
> Author: Guilhem Bichot <guilhem.bichot@oracle.com>
> Date:   Mon Nov 4 15:44:55 2013 +0100
>
>    Bug#13944462 'NULL IN (XX)' RETURNS WRONG RESULTS
2016-03-21 11:21:44 +04:00
Alexander Barkov
b25373beb5 MDEV-9653 Assertion `length || !scale' failed in uint my_decimal_length_to_precision(uint, uint, bool)
MDEV-9752 Wrong data type for COALEASCE(?,1) in prepared statements
2016-03-18 17:50:18 +04:00
Sergei Golubchik
ff93b77fd6 MDEV-9641 MDEV-9644 NULLIF assertions
* only copy args[0] to args[2] after fix_fields (when all item
  substitutions have already happened)

* change QT_ITEM_FUNC_NULLIF_TO_CASE (that allows to print NULLIF
  as CASE) to QT_ITEM_ORIGINAL_FUNC_NULLIF (that prohibits it).
  So that NULLIF-to-CASE is allowed by default and only disabled
  explicitly for SHOW VIEW|FUNCTION|PROCEDURE and mysql_make_view.
  By default it is allowed (in particular in error messages and
  debug output, that can happen anytime before or after optimizer).
2016-03-05 16:25:29 +01:00
Sergei Golubchik
a5679af1b1 Merge branch '10.0' into 10.1 2016-02-23 21:35:05 +01:00
Sergei Golubchik
271fed4106 Merge branch '5.5' into 10.0 2016-02-15 22:50:59 +01:00
Sergei Golubchik
f3444df415 Merge branch 'mysql/5.5' into 5.5
reverted about half of commits as either not applicable or
outright wrong
2016-02-09 11:27:40 +01:00
Alexander Barkov
ce40ccaf24 MDEV-9181 (NULLIF(count(table.col)), 0) gives wrong result on 10.1.x
Wrapping args[0] and args[2] into an Item_cache for aggregate functions.
2016-01-28 13:58:39 +04:00
Sergei Golubchik
a2bcee626d Merge branch '10.0' into 10.1 2015-12-21 21:24:22 +01:00
Sergei Golubchik
1623995158 Merge branch '5.5' into 10.0 2015-12-13 00:10:40 +01:00
Sergei Golubchik
abf9d35213 Merge branch 'mysql/5.5' into 5.5 2015-12-09 10:00:49 +01:00
Chaithra Gopalareddy
a7fb5aecfd Bug#19941403: FATAL_SIGNAL(SIG 6) IN BUILD_EQUAL_ITEMS_FOR_COND | IN SQL/SQL_OPTIMIZER.CC:1657
Problem:
At the end of first execution select_lex->prep_where is pointing to
a runtime created object (temporary table field). As a result
server exits trying to access a invalid pointer during second
execution.

Analysis:
While optimizing the join conditions for the query, after the
permanent transformation, optimizer makes a copy of the new
where conditions in select_lex->prep_where. "prep_where" is what
is used as the "where condition" for the query at the start of execution.
W.r.t the query in question, "where" condition is actually pointing
to a field in the temporary table. As a result, for the  second
execution the pointer is no more valid resulting in server exit.

Fix:
At the end of the first execution, select_lex->where will have the
original item of the where condition.
Make prep_where the new place where the original item of select->where
has to be rolled back.
Fixed in 5.7 with the wl#7082 - Move permanent transformations from
JOIN::optimize to JOIN::prepare

Patch for 5.5 includes the following backports from 5.6:

Bugfix for Bug12603141 - This makes the first execute statement in the testcase
pass in 5.5

However it was noted later in in Bug16163596 that the above bugfix needed to
be modified. Although Bug16163596 is reproducible only with changes done for
Bug12582849, we have decided include the fix.

Considering that Bug12582849 is related to Bug12603141, the fix is
also included here. However this results in Bug16317817, Bug16317685,
Bug16739050. So fix for the above three bugs is also part of this patch.
2015-11-20 12:30:15 +05:30
Alexander Barkov
23d4c95b50 MDEV-8896 Dead code in stored_field_cmp_to_item() 2015-10-05 16:16:13 +04:00
Alexander Barkov
ba0b668551 A clean-up for MDEV-7950:
- Turning get_mm_tree_for_const() from a static function into
  a protected method in Item.
- Adding a new class Item_bool_func2_with_rev, for the functions and operators
  that have a reverse function and can use the range optimizer for
  to optimize "value OP field" as "field REV_OP value". Deriving
  Item_bool_rowready_func2 and Item_funt_spatial_rel from the new class.
- Removing Item_bool_func2::have_rev_func().
2015-10-04 09:37:57 +04:00
Alexander Barkov
100d77e69d Clean-up: removing the unused "Item_result cmp_type" parameter from the methods:
- Item_bool_func::get_func_mm_tree()
- Item_bool_func::get_mm_parts()
- Item_bool_func::get_ne_mm_tree()
2015-10-02 14:48:32 +04:00
Alexander Barkov
22cc8f990b Changing a number of functions to aggregate argument character sets
and collations from the global name space into private and protected
methods in Item_func_or_sum.
2015-09-21 19:04:32 +04:00
Alexander Barkov
c8db0df2da Removing "DTCollation Arg_comparator::cmp_collation".
Using a CHARSET_INFO pointer instead.
2015-09-21 16:18:20 +04:00
Alexander Barkov
b75c003372 MDEV-8816 Equal field propagation is not applied for WHERE varbinary_column>=_utf8'a' COLLATE utf8_general_ci AND varbinary_column='A';
1. Removing the legacy code that disabled equal field propagation in cases
   when comparison is done as VARBINARY. This is now correctly handled by
   the new propagation code in Item_xxx::propagate_equal_fields() and
   Field_str::can_be_substituted_to_equal_item (the bug fix).
2. Also, removing legacy (pre-MySQL-4.1) Arg_comparator methods
   compare_binary_string() and compare_e_binary_string(), as VARBINARY
   comparison is correcty handled in compare_string() and compare_e_string() by
   the corresponding VARBINARY collation handler implemented in my_charset_bin.
   (not really a part of the bug fix)
2015-09-18 23:03:35 +04:00
Alexander Barkov
79140b0383 MDEV-8793 Wrong result set for SELECT ...
WHERE COALESCE(time_column)=TIME('00:00:00')
            AND COALESCE(time_column)=DATE('2015-09-11')
MDEV-8814 Wrong result for WHERE datetime_column > TIME('00:00:00')
2015-09-18 13:30:44 +04:00
Sreeharsha Ramanavarapu
4acc7615ee Bug #19929406: HANDLE_FATAL_SIGNAL (SIG=11) IN
__MEMMOVE_SSSE3_BACK FROM STRING::COPY

Issue:
-----
While using row comparators, the store_value functions call
val_xxx functions in the prepare phase. This can cause
valgrind issues.

SOLUTION:
---------
Setting up of the comparators should be done by
alloc_comparators in the prepare phase. Also, make sure
store_value will be called only during execute phase.

This is a backport of the fix for Bug#17755540.
2015-09-18 07:34:32 +05:30
Alexander Barkov
6f302d9f6c MDEV-8755 Equal field propagation is not performed any longer for the IN list when multiple comparison types 2015-09-11 11:35:15 +04:00
Alexander Barkov
0302efca7f MDEV-8705 Wrong result for SELECT..WHERE latin1_bin_column='a' AND latin1_bin_column='A'
MDEV-8712 Wrong result for SELECT..WHERE latin1_bin_column=_latin1'a' AND latin1_bin_column='A'
2015-09-11 09:20:40 +04:00
Alexander Barkov
4aebba3aeb MDEV-8740 Wrong result for SELECT..WHERE year_field=10 AND NULLIF(year_field,2011.1)='2011'
MDEV-8754 Wrong result for SELECT..WHERE year_field=2020 AND NULLIF(year_field,2010)='2020'
Problems:
1. Item_func_nullif stored a copy of args[0] in a private member m_args0_copy,
   which was invisible for the inherited Item_func menthods, like
   update_used_tables(). As a result, after equal field propagation
   things like Item_func_nullif::const_item() could return wrong result
   and a non-constant NULLIF() was erroneously treated as a constant
   at optimize_cond() time.
   Solution: removing m_args0_copy and storing the return value item
   in args[2] instead.
2. Equal field propagation did not work well for Item_fun_nullif.
   Solution: using ANY_SUBST for args[0] and args[1], as they are in
   comparison, and IDENTITY_SUBST for args[2], as it's not in comparison.
2015-09-10 17:13:35 +04:00
Alexander Barkov
8e553c455c MDEV-8785 Wrong results for EXPLAIN EXTENDED...WHERE NULLIF(latin1_col, _utf8'a' COLLATE utf8_bin) IS NOT NULL 2015-09-10 15:01:44 +04:00
Alexander Barkov
39b46ae934 MDEV-8706 Wrong result for SELECT..WHERE time_column=TIMESTAMP'2015-08-30 00:00:00' AND time_column='00:00:00' 2015-09-09 15:39:09 +04:00
Alexander Barkov
e0df116056 A clean-up after the patch for MDEV-8747 and MDEV-8749:
removing IMPOSSIBLE_RESULT from Item_result, as it's not
needed any more. The fact that an Item is not in a comparison
context is now always designated by IDENTITY_SUBST in Subst_constraint.
Previously IMPOSSIBLE_RESULT and IDENTITY_SUBST co-existed but
actually meant the same thing.
2015-09-06 13:25:47 +04:00
Alexander Barkov
c108019a48 MDEV-8747 Wrong result for SELECT..WHERE derived_table_column='a' AND derived_table_column<>_latin1'A' COLLATE latin1_bin
MDEV-8749 Wrong result for SELECT..WHERE derived_table_enum_column='number' AND derived_table_enum_column OP number
2015-09-06 01:30:46 +04:00
Alexander Barkov
3d9abaf052 MDEV-8752 Wrong result for SELECT..WHERE CASE enum_field WHEN 1 THEN 1 ELSE 0 END AND a='5' 2015-09-05 23:54:18 +04:00
Alexander Barkov
5088cbf4ed MDEV-8671 Wrong result for SELECT..WHERE varchar_column=' 1' AND (varchar_column XOR '1') 2015-09-02 15:56:24 +04:00
Alexander Barkov
8ea9b8c0b1 MDEV-8722 The patch for MDEV-8688 disabled equal field propagation for temporal column and BETWEEN and IN
Item::cmp_context was inconsistently used in combination with cmp_type()
and result_type() in different places of the code. Fixed to use cmp_type()
in all places where cmp_context is involved, to avoid unexpected results
for temporal data types (which have result_type()==STRING_RESULT and
cmp_type==TIME_RESULT).
2015-09-01 19:24:58 +04:00
Alexander Barkov
a3c24ee739 MDEV-8707 Wrong result for
SELECT..WHERE varchar_column=DATE'2001-01-01' AND varchar_column='2001-01-01'
2015-08-31 18:18:10 +04:00
Alexander Barkov
f071a12498 MDEV-8688 Wrong result for
SELECT..WHERE varchar_column IN (1,2,3) AND varchar_column=' 1';
2015-08-29 19:26:30 +04:00
Alexander Barkov
09fb51255a Clean-up: removing duplicate code: removing
Item_func_in::compare_collation() and Item_func_between::compare_collation(),
and adding Item_func_opt_neg::compare_collation() instead.
2015-08-29 18:45:04 +04:00
Alexander Barkov
b4e56a5658 Moving common members of Item_func_in and Item_func_between to their
parent Item_func_opt_neg. A pre-requisite patch for a number of
upcoming equal field propagation related bug fixes.
2015-08-29 16:31:11 +04:00