Commit graph

3512 commits

Author SHA1 Message Date
Alexander Barkov
29bbf4749e MDEV-19699 Server crashes in Item_null_result::field_type upon SELECT with ROLLUP on constant table
Also fixes:

MDEV-20431 GREATEST(int_col,date_col) returns wrong results in a view
2019-08-27 09:13:20 +04:00
Oleksandr Byelkin
ae476868a5 Merge branch '5.5' into 10.1 2019-07-25 13:27:11 +02:00
Oleksandr Byelkin
1a79a29c87 MDEV-17042: prepared statement does not return error with SQL_MODE STRICT_TRANS_TABLES.
Use for parameters value conversion functions which issue warnings.
2019-07-12 14:29:12 +02:00
Igor Babaev
645191aa13 MDEV-19778 Wrong Result on Left Outer Join with Subquery right on true
and WHERE filter afterwards

This patch complements the patch fixing the bug MDEV-6892. The latter
properly handled queries that used mergeable views returning constant
columns as inner tables of outer joins and whose where clause contained
predicates referring to these columns if the predicates of happened not
to be equality predicates. Otherwise the server still could return wrong
result sets for such queries. Besides the fix for MDEV-6892 prevented
some possible conversions of outer joins to inner joins for such queries.

This patch corrected the function check_simple_equality() to handle
properly conjunctive equalities of the where clause that refer to the
constant columns of mergeable views used as inner tables of an outer join.
The patch also changed the code of Item_direct_view_ref::not_null_tables().
This change allowed to take into account predicates containing references
to constant columns of mergeable views when converting outer joins into
inner joins.
2019-06-22 09:18:24 -07:00
Vicențiu Ciorbaru
cb248f8806 Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
Vicențiu Ciorbaru
5543b75550 Update FSF Address
* Update wrong zip-code
2019-05-11 21:29:06 +03:00
Alexander Barkov
78c2499282 MDEV-16958 Assertion `field_length < 5' failed in Field_year::val_str or data corruption upon SELECT with UNION and aggregate functions 2019-03-15 11:37:29 +04:00
Alexander Barkov
17c75bd272 MDEV-18195 ASAN use-after-poison in my_strcasecmp_utf8 / Item::eq upon prepared statement with ORDER BY NAME_CONST
ASAN noticed a freed memory access during EXECUTE in this script:
  PREPARE stmt FROM "SELECT 'x' ORDER BY NAME_CONST( 'f', 'foo' )";
  EXECUTE stmt;

In case of a PREPARE statement, all Items, including Item_name_const,
are created on Prepared_statement::main_mem_root.
Item_name_const::fix_fields() did not take this into account
and could allocate the value of Item::name on a wrong memory root,
in this code:

  if (is_autogenerated_name)
  {
    set_name(thd, item_name->c_ptr(), (uint) item_name->length(),
             system_charset_info);
  }

When fix_fields() is called in the reported SQL script, THD's arena already
points to THD::main_mem_root rather than to Prepared_statement::main_mem_root,
so Item::name was allocated on THD::main_mem_root.
Then, at the end of the dispatch_command() for the PREPARE statement,
THD::main_mem_root got cleared. So during EXECUTE, Item::name
pointed to an already freed memory.

This patch changes the code to set the implicit name for Item_name_const
at the constructor time rather than at fix_fields time. This guarantees
that Item_name_const and its Item::name always reside on the same memory root.

Note, this change makes the code for Item_name_const symmetric with other
constant-alike items that set their default implicit names at the constructor
call time rather than at fix_fields() time:
- Item_string
- Item_int
- Item_real
- Item_decimal
- Item_null
- Item_param
2019-01-24 17:54:29 +04:00
Sergei Golubchik
1fc5a6f30c Merge branch '10.0' into 10.1 2018-09-23 12:58:11 +02:00
Alexander Barkov
80bcb05b24 Merge remote-tracking branch 'origin/5.5' into 10.0 2018-09-21 08:37:42 +04:00
Alexander Barkov
e07118946a MDEV-17250 Remove unused Item_copy_xxx 2018-09-20 17:11:36 +04:00
Alexander Barkov
0c6455aa46 MDEV-17249 MAKETIME(-1e50,0,0) returns a wrong result 2018-09-20 16:02:58 +04:00
Oleksandr Byelkin
31081593aa Merge branch '11.0' into 10.1 2018-09-06 22:45:19 +02:00
Oleksandr Byelkin
b9bc3c2463 Merge branch '5.5' into 10.0 2018-09-03 10:57:02 +02:00
Daniel Black
064ba8cc9f item_cmp_type: simplier for a faster codepath
The common case for this function is that both types are the same.

The Item_result defination from include/mysql.h.pp is the following enum
   enum Item_result
   {
     STRING_RESULT=0, REAL_RESULT, INT_RESULT, ROW_RESULT, DECIMAL_RESULT,
     TIME_RESULT
   };

The compilers aren't quite smart enough to optimize to this shortcut so
this makes it quicker.

Before the change:

0000000000012730 <item_cmp_type(Item_result, Item_result)>:
   12730:       89 f0                   mov    %esi,%eax
   12732:       09 f8                   or     %edi,%eax
   12734:       74 4c                   je     12782 <item_cmp_type(Item_result, Item_result)+0x52>
   12736:       83 ff 02                cmp    $0x2,%edi
   12739:       75 0a                   jne    12745 <item_cmp_type(Item_result, Item_result)+0x15>
   1273b:       b8 02 00 00 00          mov    $0x2,%eax
   12740:       83 fe 02                cmp    $0x2,%esi
   12743:       74 3c                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12745:       83 ff 03                cmp    $0x3,%edi
   12748:       b8 03 00 00 00          mov    $0x3,%eax
   1274d:       74 32                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   1274f:       83 fe 03                cmp    $0x3,%esi
   12752:       74 2d                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12754:       83 ff 05                cmp    $0x5,%edi
   12757:       b8 05 00 00 00          mov    $0x5,%eax
   1275c:       74 23                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   1275e:       83 fe 05                cmp    $0x5,%esi
   12761:       74 1e                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12763:       83 ff 04                cmp    $0x4,%edi
   12766:       74 05                   je     1276d <item_cmp_type(Item_result, Item_result)+0x3d>
   12768:       83 ff 02                cmp    $0x2,%edi
   1276b:       75 0f                   jne    1277c <item_cmp_type(Item_result, Item_result)+0x4c>
   1276d:       b8 04 00 00 00          mov    $0x4,%eax
   12772:       83 fe 02                cmp    $0x2,%esi
   12775:       74 0a                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   12777:       83 fe 04                cmp    $0x4,%esi
   1277a:       74 05                   je     12781 <item_cmp_type(Item_result, Item_result)+0x51>
   1277c:       b8 01 00 00 00          mov    $0x1,%eax
   12781:       c3                      retq
   12782:       31 c0                   xor    %eax,%eax
   12784:       c3                      retq

After, noting the short cut and the beginning of the function:

0000000000012730 <item_cmp_type(Item_result, Item_result)>:
   12730:       39 f7                   cmp    %esi,%edi
   12732:       75 03                   jne    12737 <item_cmp_type(Item_result, Item_result)+0x7>
   12734:       89 f8                   mov    %edi,%eax
   12736:       c3                      retq
   12737:       83 ff 03                cmp    $0x3,%edi
   1273a:       b8 03 00 00 00          mov    $0x3,%eax
   1273f:       74 32                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12741:       83 fe 03                cmp    $0x3,%esi
   12744:       74 2d                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12746:       83 ff 05                cmp    $0x5,%edi
   12749:       b8 05 00 00 00          mov    $0x5,%eax
   1274e:       74 23                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12750:       83 fe 05                cmp    $0x5,%esi
   12753:       74 1e                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12755:       83 ff 04                cmp    $0x4,%edi
   12758:       74 05                   je     1275f <item_cmp_type(Item_result, Item_result)+0x2f>
   1275a:       83 ff 02                cmp    $0x2,%edi
   1275d:       75 0f                   jne    1276e <item_cmp_type(Item_result, Item_result)+0x3e>
   1275f:       b8 04 00 00 00          mov    $0x4,%eax
   12764:       83 fe 02                cmp    $0x2,%esi
   12767:       74 0a                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   12769:       83 fe 04                cmp    $0x4,%esi
   1276c:       74 05                   je     12773 <item_cmp_type(Item_result, Item_result)+0x43>
   1276e:       b8 01 00 00 00          mov    $0x1,%eax
   12773:       c3                      retq

Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>
2018-08-22 09:39:30 +03:00
Oleksandr Byelkin
b4210f3640 Merge branch '10.0' into 10.1 2018-08-21 10:07:26 +02:00
Oleksandr Byelkin
bcc677bb72 Merge branch '5.5' into 10.0 2018-08-15 16:48:13 +02:00
Oleksandr Byelkin
1b797e9e63 MDEV-15475: Assertion `!table || (!table->read_set || bitmap_is_set(table->read_set, field_index))' failed on EXPLAIN EXTENDED with constant table and view
Print constant ISNULL value independent.
Fix of printing of view FRM and CREATE VIEW output
2018-08-15 14:23:07 +02:00
Oleksandr Byelkin
865e807125 Merge branch '10.0' into 10.1 2018-07-31 11:58:29 +02:00
Marko Mäkelä
91181b225c Merge 5.5 into 10.0 2018-07-30 15:09:25 +03:00
Oleksandr Byelkin
fceda2dab6 Merge remote-tracking branch 'mysql/5.5' into 5.5
We do not accept:
1. We did not have this problem (fixed earlier and better)
 d982e717ab Bug#27510150: MYSQLDUMP FAILS FOR SPECIFIC --WHERE CLAUSES
2. We do not have such options (an DBUG_ASSERT put just in case)
 bbc2e37fe4 Bug#27759871: BACKRONYM ISSUE IS STILL IN MYSQL 5.7
3. Serg fixed it in other way in this release:
 e48d775c6f Bug#27980823: HEAP OVERFLOW VULNERABILITIES IN MYSQL CLIENT LIBRARY
2018-07-29 13:10:29 +02:00
Alexander Barkov
5227198908 MDEV-16190 Server crashes in Item_null_result::field_type on SELECT with time field, ROLLUP and HAVING
virtual Item_null_result::get_date() was not overridden.
It used the inherited Item::get_date(), which tests field_type(),
which in case of Item_null_result calls result_field->field_type(),
and result_field is not really always set (e.g. it's not set in the
test case from the bug report).

Overriding Item_null::get_date() like it's done for other val_xxx() methods.
This make the code more symmetric across data types.

In the new reduction, get_date() immediately returns NULL without entering
into any data type specific code.
2018-06-11 16:29:22 +04:00
Sergei Golubchik
91dfb6141f Merge branch '10.0' into 10.1 2018-05-19 22:05:55 +02:00
Sergei Golubchik
c1b5d2801e Merge branch '5.5' into 10.0 2018-05-19 15:38:34 +02:00
Sergei Golubchik
1b2078b4d8 MDEV-15318 CREATE .. SELECT VALUES produces invalid table structure
When Item_insert_value needs a dummy field,
use zero-length Field_string, not Field_null.
The latter isn't compatible with CREATE ... SELECT.
2018-05-17 11:32:13 +02:00
Sergei Golubchik
9989c26bc9 Merge branch '10.0' into 10.1 2018-05-05 14:01:59 +02:00
Sergei Golubchik
c4499a0391 Merge branch '5.5' into 10.0 2018-04-29 00:38:10 +02:00
Igor Babaev
eb057dce20 MDEV-15035 Wrong results when calling a stored procedure
multiple times with different arguments.

If the ON expression of an outer join is an OR formula with one
of the disjunct being a constant formula then the expression
cannot be null-rejected if the constant formula is true. Otherwise
it can be null-rejected and if so the outer join can be converted
into inner join. This optimization was added in the patch for
mdev-4817. Yet the code had a defect: if the query was used in
a stored procedure with parameters and the constant item contained
some of them then the value of this constant item depended on the
values of the parameters. With some parameters it may be true,
for others not. The validity of conversion to inner join is checked
only once and it happens only for the first call of procedure.
So if the  parameters in the first call allowed the conversion it
was done and next calls used the transformed query though there
could be calls whose parameters made the conversion invalid.

Fixed by cheking whether the constant disjunct in the ON expression
originally contained an SP parameter. If so the expression is not
considered as null-rejected. For this check a new item's attribute
was intruduced: Item::with_param. It is calculated for each item
by fix fields() functions.
Also moved the call of optimize_constant_subqueries() in
JOIN::optimize after the call of simplify_joins(). The reason
for this is that after the optimization introduced by the patch
for mdev-4817 simplify_joins() can use the results of execution
of non-expensive constant subqueries and this is not valid.
2018-04-25 09:22:06 -07:00
Ajo Robert
940b88b686 Bug#27197235 USER VARIABLE + UINON + DECIMAL COLUMN RETURNS
WRONG VALUES

User variables will have the default session collation
associated with it. And a select which uses it as part of a
union may infer the collation while type merging.
This leads to problems when the result is of DECIMAL type.
Setting the appropriate collation of DECIMAL result type
is missing in 5.7 code base.

Added code to set appropriate collation when the result is
of DECIMAL type during Item_type_holder::join_types().
2018-04-10 00:30:59 +05:30
Varun Gupta
a0c722d853 MDEV-15321:different results when using value of optimizer_use_condition_selectivity=4 and =1
To disallow equality propagation for DATETIME with non-zero YYYYMMDD part we were setting null_value to true.
This caused issues when we were calculating selectivity for a condition as this returned IMPOSSIBLE WHERE.

The issue is resolved by not setting null_value to true for DATETIME with non-zero YYYYMMDD.
2018-03-16 18:35:41 +05:30
Sergei Golubchik
d4df7bc9b1 Merge branch 'github/10.0' into 10.1 2018-02-02 10:09:44 +01:00
Vicențiu Ciorbaru
d833bb65d5 Merge remote-tracking branch '5.5' into 10.0 2018-01-24 12:29:31 +02:00
Oleksandr Byelkin
ba8d0fa700 MDEV-14786: Server crashes in Item_cond::transform on 2nd execution of SP querying from a view
MDEV-14957: JOIN::prepare gets unusable "conds" as argument

Do not touch merged derived (it is irreversible)

Fix first argument of in_optimizer for calls possible before fix_fields()
2018-01-23 13:42:41 +01:00
Sergei Golubchik
2d52d3c1bf Merge branch 'mysql/5.5' into 5.5 2018-01-18 17:54:48 +01:00
Vicențiu Ciorbaru
e3d89652e5 Merge branch '10.0' into 10.1 2017-12-20 13:30:05 +02:00
Vicențiu Ciorbaru
042f763268 Merge remote-tracking branch '5.5' into 10.0 2017-12-20 12:51:57 +02:00
Vicențiu Ciorbaru
ac61a575df Revert "Remove use of volatile in stored_field_cmp_to_item"
This reverts commit 7603463a46.

The commit itself is fine, however when disabling volatile, compiler
optimizations mess up our double results due to precision differences.
Revert the patch till a proper solution is found.
2017-12-06 02:16:14 +02:00
Daniel Black
7603463a46 Remove use of volatile in stored_field_cmp_to_item
This was added in c796415943 but would hurt all other compilers
because of Visual Studio. Hopefully this has been fixed now.

Signed-off-by: Daniel Black <daniel@linux.vnet.ibm.com>
2017-12-05 12:09:43 +02:00
Sreeharsha Ramanavarapu
f06443ce5f Bug : INCORRECT BEHAVIOR WITH "VALUES"
Issue:
------
VALUES doesn't have a type() function and is considered a
Item_field.

Solution for 5.7:
-----------------
Add a new type() function for Item_values_insert.

On 8.0 and trunk it was fixed by Mithun's Bug#19601973.

Solution for 5.6:
-----------------
Additionally Bug#17458914 is backported.

This will address the problem of using VALUES() in
INSERT ... ON DUPLICATE KEY UPDATE. Create a field object
only if it is in the UPDATE clause, else return a NULL
item.

This will also address the problems mentioned in
Bug#14789787 and Bug#16756402.

Solution for 5.5:
-----------------
As mentioned above Bug#17458914 is backported.

Additionally Bug#14786324 is also backported.

When VALUES() is detected outside its meaningful place,
it should be treated as NULL and is thus replaced with a
Field_null object, with the same name as the original
field.

Fields with type NULL are generally not handled well inside
the server (e.g Innodb will not accept them and it is
impossible to create them in regular tables). So create a
new const NULL item instead.
2017-11-16 09:31:12 +05:30
Igor Babaev
b5cb4ae470 Fixed bug MDEV-14368 Improper error for a grouping query that
uses alias in HAVING when sql_mode = 'ONLY_FULL_GROUP_BY'

This patch corrects the patch for bug#18739: non-standard
HAVING extension was allowed in strict ANSI sql mode
added in 2006 by commit 4b7c4cd27f.
As a result of incompleteness of the fix in the above commit
if a query with GROUP BY contained an aggregate function with an
alias and this alias was used in the HAVING clause of the query
the server reported an error when sql_mode was set to
'ONLY_FULL_GROUP_BY'.
2017-11-11 11:45:59 -08:00
Alexander Barkov
0fdb0bdf27 Merge remote-tracking branch 'origin/10.0' into 10.1 2017-11-09 14:05:53 +04:00
Oleksandr Byelkin
c2c93fc6e4 MDEV-14164: Unknown column error when adding aggregate to function in oracle style procedure FOR loop
Make differentiation between pullout for merge and pulout of outer field during exists2in transformation.
In last case the field was outer and so we can safely start from name resolution context of the SELECT where it was pulled.
Old behavior lead to inconsistence between list of tables and outer name resolution context (which skips one SELECT for merge purposes) which creates problem vor name resolution.
2017-11-09 09:31:03 +01:00
Sergei Golubchik
9d2e2d7533 Merge branch '10.0' into 10.1 2017-10-22 13:03:41 +02:00
Sergei Golubchik
da4503e956 Merge branch '5.5' into 10.0 2017-10-18 15:14:39 +02:00
Sergei Golubchik
b000e16956 Bug#26361149 MYSQL SERVER CRASHES AT: COL IN(IFNULL(CONST, COL), NAME_CONST('NAME', NULL))
based on:

commit f7316aa0c9
Author: Ajo Robert <ajo.robert@oracle.com>
Date:   Thu Aug 24 17:03:21 2017 +0530

    Bug#26361149  MYSQL SERVER CRASHES AT: COL IN(IFNULL(CONST,
                           COL), NAME_CONST('NAME', NULL))

    Backport of Bug#19143243 fix.

    NAME_CONST item can return NULL_ITEM type in case of incorrect arguments.
    NULL_ITEM has special processing in Item_func_in function.
    In Item_func_in::fix_length_and_dec an array of possible comparators is
    created. Since NAME_CONST function has NULL_ITEM type, corresponding
    array element is empty. Then NAME_CONST is wrapped to ITEM_CACHE.
    ITEM_CACHE can not return proper type(NULL_ITEM) in Item_func_in::val_int(),
    so the NULL_ITEM is attempted compared with an empty comparator.
    The fix is to disable the caching of Item_name_const item.
2017-10-17 11:04:09 +02:00
Sergei Golubchik
d76f5774fe MDEV-13459 Warnings, when compiling with gcc-7.x
mostly caused by -Wimplicit-fallthrough
2017-10-17 07:37:39 +02:00
Oleksandr Byelkin
3b7aa3017b Cleanup usage of DBUG_ASSERTS. 2017-10-13 19:32:38 +02:00
Oleksandr Byelkin
a4868c3509 MDEV-9208: Function->Function->View = Mysqld segfault (Server crashes in Dependency_marker::visit_field on 2nd execution with merged subquery)
Prevent crossing name resolution border in finding item tables.
2017-10-13 12:35:17 +02:00
Alexander Barkov
ca948e335e MDEV-9886 Illegal mix of collations with a view comparing a field to a binary constant 2017-10-07 13:42:11 +04:00
Vicențiu Ciorbaru
ec6042bda0 Merge branch '10.0' into 10.1 2017-09-19 12:06:50 +03:00