Commit graph

4103 commits

Author SHA1 Message Date
Sergei Golubchik
3bc98a4ec4 Merge branch '10.5' into 10.6 2022-05-10 14:01:23 +02:00
Sergei Golubchik
ef781162ff Merge branch '10.4' into 10.5 2022-05-09 22:04:06 +02:00
Sergei Golubchik
a8e57906d1 10.4 specific fixes for DEFAULT() 2022-05-09 12:21:02 +02:00
Sergei Golubchik
a70a1cf3f4 Merge branch '10.3' into 10.4 2022-05-08 23:03:08 +02:00
Sergei Golubchik
bc9102eb81 cleanup: (*order->item) -> item
and minor style fixes
2022-04-29 17:05:12 +02:00
Marko Mäkelä
fae0ccad6e Merge 10.5 into 10.6 2022-04-21 17:46:40 +03:00
Marko Mäkelä
620c55e708 Merge 10.4 into 10.5 2022-04-21 15:33:50 +03:00
Marko Mäkelä
394784095e Merge 10.3 into 10.4 2022-04-21 11:33:59 +03:00
Sergei Golubchik
6f6c74b0d1 Merge branch '10.2' into 10.3 2022-04-21 10:05:50 +02:00
Aleksey Midenkov
08c7ab404f MDEV-24176 Server crashes after insert in the table with virtual
column generated using date_format() and if()

vcol_info->expr is allocated on expr_arena at parsing stage. Since
expr item is allocated on expr_arena all its containee items must be
allocated on expr_arena too. Otherwise fix_session_expr() will
encounter prematurely freed item.

When table is reopened from cache vcol_info contains stale
expression. We refresh expression via TABLE::vcol_fix_exprs() but
first we must prepare a proper context (Vcol_expr_context) which meets
some requirements:

1. As noted above expr update must be done on expr_arena as there may
be new items created. It was a bug in fix_session_expr_for_read() and
was just not reproduced because of no second refix. Now refix is done
for more cases so it does reproduce. Tests affected: vcol.binlog

2. Also name resolution context must be narrowed to the single table.
Tested by: vcol.update main.default vcol.vcol_syntax gcol.gcol_bugfixes

3. sql_mode must be clean and not fail expr update.

sql_mode such as MODE_NO_BACKSLASH_ESCAPES, MODE_NO_ZERO_IN_DATE, etc
must not affect vcol expression update. If the table was created
successfully any further evaluation must not fail. Tests affected:
main.func_like

Reviewed by: Sergei Golubchik <serg@mariadb.org>
2022-04-18 12:44:27 +03:00
Aleksey Midenkov
c02ebf3510 MDEV-24176 Preparations
1. moved fix_vcol_exprs() call to open_table()

mysql_alter_table() doesn't do lock_tables() so it cannot win from
fix_vcol_exprs() from there. Tests affected: main.default_session

2. Vanilla cleanups and comments.
2022-04-18 12:44:27 +03:00
Sergei Golubchik
cc08c43ed6 cleanup: remove Item_default_value::cached_field 2022-04-14 15:43:35 +02:00
Sergei Golubchik
b5e16a6e03 MDEV-26061 MariaDB server crash at Field::set_default
* Item_default_value::fix_fields creates a copy of its argument's field.
* Field::default_value is changed when its expression is prepared in
  unpack_vcol_info_from_frm()

This means we must unpack any vcol expression that includes DEFAULT(x)
strictly after unpacking x->default_value.

To avoid building and solving this dependency graph on every table open,
we update Item_default_value::field->default_value after all vcols
are unpacked and fixed.
2022-04-14 15:43:35 +02:00
Alexander Barkov
2ae92e8981 MDEV-28267 ASAN heap-use-after-free in Item_sp::func_name_cstring
This crash happens on a combination of multiple conditions:

- There is a thead#1 running an "ANALYZE FORMAT=JSON" query for a
  "SELECT .. FROM INFORMATION_SCHEMA.COLUMNS WHERE .. "
- The WHERE clause contains a stored function call, say f1().
- The WHERE clause is built in the way so that the function f1()
  is never actually called, e.g.
    WHERE .. AND (TRUE OR f1()=expr)
- The database contains multiple VIEWs that have the function f1() call,
  e.g. in their <select list>
- The WHERE clause is built in the way so that these VIEWs match
  the condition.
- There is a parallel thread#2 running. It creates or drops or recreates
  some other stored routine, say f2(), which is not used in the ANALYZE query.
  It effectively invalidates the stored routine cache for thread#1
  without locking.
  Note, it is important that f2() is NOT used by ANALYZE query.
  Otherwise, thread#2 would be locked until the ANALYZE query
  finishes.

When all of the above conditions are met, the following happens:

1. thread#1 starts the ANALYZE query. It notices a call for the stored function
   f1() in the WHERE condition. The function f1() gets parsed and cached
   to the SP cache. Its address also gets assigned to Item_func_sp::m_sp.

2. thread#1 starts iterating through all tables that
   match the WHERE condition to find the information about their columns.

3. thread#1 processes columns of the VIEW v1.
   It notices a call for f1() in the VIEW v1 definition.
   But f1() is already cached in the step#1 and it is up to date.
   So nothing happens with the SP cache.

4. thread#2 re-creates f2() in a non-locking mode.
   It effectively invalidates the SP cache in thread#1.

5. thread#1 processes columns of the VIEW v2.
   It notices a call for f1() in the VIEW v2 definition.
   It also notices that the cached version of f1() is not up to date.
   It frees the old definition of f1(), parses it again, and puts a
   new version of f1() to the SP cache.

6. thread#1 finishes processing rows and generates the JSON output.
   When printing the "attached_condition" value, it calls
   Item_func_sp::print() for f1(). But this Item_func_sp links
   to the old (freed) version of f1().

The above scenario demonstrates that Item_func_sp::m_sp can point to an
alredy freed instance when Item_func_sp::func_name() is called,
so accessing to Item_sp::m_sp->m_handler is not safe.

This patch rewrites the code to use Item_func_sp::m_handler instead,
which is always reliable.

Note, this patch is only a cleanup for MDEV-28166 to quickly fix the regression.
It fixes MDEV-28267. But it does not fix the core problem:
The code behind I_S does not take into account that the SP
cache can be updated while evaluating rows of the COLUMNS table.
This is a corner case and it never happens with any other tables.
I_S.COLUMNS is very special.

Another example of the core problem is reported in MDEV-25243.
The code accesses to Item_sp::m_sp->m_chistics of an
already freed m_sp, again. It will be addressed separately.
2022-04-09 23:01:26 +04:00
Marko Mäkelä
b242c3141f Merge 10.5 into 10.6 2022-03-29 16:16:21 +03:00
Marko Mäkelä
d62b0368ca Merge 10.4 into 10.5 2022-03-29 12:59:18 +03:00
Marko Mäkelä
ae6e214fd8 Merge 10.3 into 10.4 2022-03-29 11:13:18 +03:00
Alexander Barkov
6437b30404 MDEV-28166 sql_mode=ORACLE: fully qualified package function calls do not work: db.pkg.func()
Also fixes MDEV-19328 sql_mode=ORACLE: Package function in VIEW
2022-03-25 10:46:59 +04:00
Oleksandr Byelkin
f5c5f8e41e Merge branch '10.5' into 10.6 2022-02-03 17:01:31 +01:00
Oleksandr Byelkin
cf63eecef4 Merge branch '10.4' into 10.5 2022-02-01 20:33:04 +01:00
Oleksandr Byelkin
a576a1cea5 Merge branch '10.3' into 10.4 2022-01-30 09:46:52 +01:00
Oleksandr Byelkin
41a163ac5c Merge branch '10.2' into 10.3 2022-01-29 15:41:05 +01:00
Alexander Barkov
e4b302e436 MDEV-27018 IF and COALESCE lose "json" property
Hybrid functions (IF, COALESCE, etc) did not preserve the JSON property
from their arguments. The same problem was repeatable for single row subselects.

The problem happened because the method Item::is_json_type() was inconsistently
implemented across the Item hierarchy. For example, Item_hybrid_func
and Item_singlerow_subselect did not override is_json_type().

Solution:

- Removing Item::is_json_type()

- Implementing specific JSON type handlers:
  Type_handler_string_json
  Type_handler_varchar_json
  Type_handler_tiny_blob_json
  Type_handler_blob_json
  Type_handler_medium_blob_json
  Type_handler_long_blob_json

- Reusing the existing data type infrastructure to pass JSON
  type handlers across all item types, including classes Item_hybrid_func
  and Item_singlerow_subselect. Note, these two classes themselves do not
  need any changes!

- Extending the data type infrastructure so data types can inherit
  their properties (e.g. aggregation rules) from their base data types.
  E.g. VARCHAR/JSON acts as VARCHAR, LONGTEXT/JSON acts as LONGTEXT
  when mixed to a non-JSON data type. This is done by:
    - adding virtual method Type_handler::type_handler_base()
    - adding a helper class Type_handler_pair
    - refactoring Type_handler_hybrid_field_type methods
      aggregate_for_result(), aggregate_for_min_max(),
      aggregate_for_num_op() to use Type_handler_pair.

This change also fixes:

  MDEV-27361 Hybrid functions with JSON arguments do not send format metadata

Also, adding mtr tests for JSON replication. It was not covered yet.
And the current patch changes the replication code slightly.
2022-01-21 19:28:48 +04:00
Igor Babaev
7692cec5b0 MDEV-25631 Crash executing query with VIEW, aggregate and subquery
This bug could cause a crash of the server for queries with a derived table
whose specification contained the set function using a subquery over a view
as its only argument. The crash could happen if the specification of the
view contained an outer reference. In this case the aggregation select
could be determined incorrectly.
The crash also could be observed if a CTE is used instead of the view, but
only for queries having at least two references to the CTE.
2022-01-10 09:12:17 -08:00
Igor Babaev
6dec0332fb MDEV-25086 Stored Procedure Crashes Server
The cause of this bug is the same as of the bug MDEV-24454.
This bug manifested itself at the second execution of the queries that
contained a set function whose only argument was outer reference to
a column of a mergeable view or derived table or CTE. The first execution
of such query worked fine, but the second execution of the query caused
a crash of the server because the aggregation select for the used set
function was determined incorrectly at the name resolution phase of the
second execution.
2022-01-10 09:12:17 -08:00
Igor Babaev
d6ee351bbb Revert "MDEV-24454 Crash at change_item_tree"
This patch reverts the fixes of the bugs MDEV-24454 and MDEV-25631 from
the commit 3690c549c6.
It leaves the changes in plugin/feedback/feedback.cc and corresponding
test files introduced in this commit intact.

Proper fixes for the bug MDEV-24454 and MDEV-25631 will follow immediately.
2022-01-10 09:12:17 -08:00
Alexander Barkov
189bf300ca MDEV-21639 DEFAULT(col) evaluates to a bad value in WHERE clause
The problem happened because Item_default_value did not overload
properly the val_xxx_result() family methods.

This change backports the patch for:
MDEV-24958 Server crashes in my_strtod / Value_source::Converter_strntod::Converter_strntod with DEFAULT(blob)
which earlier fixed the problem in 10.3.
2021-12-29 14:54:34 +04:00
Marko Mäkelä
d4a89b9262 Merge 10.5 into 10.6 2021-10-27 10:06:02 +03:00
Marko Mäkelä
44f9736e0b Merge 10.4 into 10.5 2021-10-27 09:48:22 +03:00
Alexander Barkov
7b75242918 Merge remote-tracking branch 'origin/10.3' into 10.4 2021-10-27 07:14:45 +04:00
Alexander Barkov
e97b785d76 MDEV-22380: Assertion `name.length == strlen(name.str)' failed ...
Also fixes:
MDEV-25399 Assertion `name.length == strlen(name.str)' failed in Item_func_sp::make_send_field

Also fixes a problem that in this scenario:

SET NAMES binary;
SELECT 'some not well-formed utf8 string';

the auto-generated column name copied the binary string value directly
to the Item name, without checking utf8 well-formedness.

After this change auto-generated column names work as follows:
- Zero bytes 0x00 are copied to the name using HEX notation
- In case of "SET NAMES binary", all bytes sequences that do not make
  well-formed utf8 characters are copied to the name using HEX notation.
2021-10-27 06:09:57 +04:00
Marko Mäkelä
73f5cbd0b6 Merge 10.5 into 10.6 2021-10-21 16:06:34 +03:00
Marko Mäkelä
5f8561a6bc Merge 10.4 into 10.5 2021-10-21 15:26:25 +03:00
Marko Mäkelä
489ef007be Merge 10.3 into 10.4 2021-10-21 14:57:00 +03:00
Marko Mäkelä
e4a7c15dd6 Merge 10.2 into 10.3 2021-10-21 13:41:04 +03:00
Alexander Barkov
a2a42f4eba MDEV-23408 Wrong result upon query from I_S and further Assertion `!alias_arg || strlen(alias_arg->str) == alias_arg->length' failed with certain connection charset
There were two independent problems which lead to the crash
and to the non-relevant records returned in I_S queries:

- The code in the I_S implementation was not secure
  about values with 0x00 bytes.
  It's fixed by using check_db_name() and check_table_name()
  inside make_table_name_list(), and by adding the test for
  0x00 inside check_table_name().

- The code in Item_string::print() did not convert
  strings without introducers when restoring
  the CREATE VIEW statement from an Item tree.
  This made wrong literals inside the "query" line in the view FRM file
  in cases when the VIEW parse time
  character_set_client!=character_set_connection.
  That's fixed by adding a proper conversion.

  This change also fixed a similar problem in SHOW PROCEDURE CODE -
  the literals were displayed in wrong character set in SP instructions
  in cases when the SP parse time
  character_set_client!=character_set_connection.
2021-10-14 10:16:23 +04:00
Marko Mäkelä
a49e394399 Merge 10.5 into 10.6 2021-09-30 10:38:44 +03:00
Marko Mäkelä
064cb58efe Merge 10.4 into 10.5
FIXME: Part of the MDEV-20699 test is disabled due to
nonderterministic result.
2021-09-30 09:04:43 +03:00
Marko Mäkelä
a10b63bf58 Merge 10.3 into 10.4 2021-09-29 16:03:02 +03:00
Marko Mäkelä
742b37a345 Merge 10.2 into 10.3 2021-09-29 15:04:20 +03:00
Oleksandr Byelkin
3690c549c6 MDEV-24454 Crash at change_item_tree
Use in_sum_func (and so nest_level) only in LEX to which SELECT lex belong to

Reduce usage of current_select (because it does not always point on the correct
 SELECT_LEX, for example with prepare.

Change context for all classes inherited from Item_ident (was only for Item_field) in case of pushing down it to HAVING.

Now name resolution context have to have SELECT_LEX reference if the context is present.

Fixed feedback plugin stack usage.
2021-09-27 11:00:51 +02:00
Sergei Golubchik
b9e2002702 cleanup: only do work when needed 2021-09-05 21:08:18 +02:00
Oleksandr Byelkin
6efb5e9f5e Merge branch '10.5' into 10.6 2021-08-02 10:11:41 +02:00
Oleksandr Byelkin
ae6bdc6769 Merge branch '10.4' into 10.5 2021-07-31 23:19:51 +02:00
Oleksandr Byelkin
7841a7eb09 Merge branch '10.3' into 10.4 2021-07-31 22:59:58 +02:00
Sergei Golubchik
eaae13059f MDEV-25808 PREPARE/EXECUTE makes signed integer out of unsigned
Closes 
2021-07-24 10:14:30 +02:00
Nikita Malyavin
c47e4aab62 MDEV-23597 Assertion `marked_for_read()' failed while evaluating DEFAULT
The columns that are part of DEFAULT expression were not read-marked
in statements like UPDATE...SET b=DEFAULT.

The problem is `F(DEFAULT)` expression depends of the left-hand side of an
assignment. However, setup_fields accepts only right-hand side value.
Neither Item::fix_fields does.

Suchwise, b=DEFAULT(b) works fine, because Item_default_field has
information on what field it is default of:
    if (thd->mark_used_columns != MARK_COLUMNS_NONE)
      def_field->default_value->expr->update_used_tables();

in Item_default_value::fix_fields().

It is not reasonable to pass a left-hand side to Item:fix_fields, because
the case is rare, so the rewrite
  b= F(DEFAULT)  ->  b= F(DEFAULT(b))

is made instead.

Both UPDATE and multi-UPDATE are affected, however any form of INSERT
is not: it marks all the fields in DEFAULT expressions for read in
TABLE::mark_default_fields_for_write().
2021-07-16 13:31:19 +03:00
Marko Mäkelä
a42c80bd48 Merge 10.4 into 10.5 2021-06-21 14:22:22 +03:00
Marko Mäkelä
d3e4fae797 Merge 10.3 into 10.4 2021-06-21 12:38:25 +03:00
Marko Mäkelä
c9a85fb1b1 Merge 10.2 into 10.3 2021-06-21 09:07:40 +03:00