1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-08 11:22:35 +03:00
Commit Graph

8648 Commits

Author SHA1 Message Date
Rucha Deodhar
452c9a4d72 MDEV-26698: Incorrect row number upon INSERT .. SELECT from the same
table: rows are counted twice

Analysis: When the table we are trying to insert into and the SELECT table
are same for INSERT ... SELECT, rows from the SELECT table are copied into
internal temporary table and then to the INSERT table. We only want to
count the rows when we start inserting into the table.
Fix: Reset the counter to 1 before starting to copy from internal temporary
table to select table and then increment the counter.
2022-01-03 18:14:59 +05:30
Julius Goryavsky
55bb933a88 Merge branch 10.4 into 10.5 2021-12-26 12:51:04 +01:00
Julius Goryavsky
681b7784b6 Merge branch 10.3 into 10.4 2021-12-25 12:13:03 +01:00
Julius Goryavsky
3376668ca8 Merge branch 10.2 into 10.3 2021-12-23 14:14:04 +01:00
Sergei Petrunia
4b020bfd9a Fix typos in optimizer trace output 2021-12-23 14:08:43 +03:00
Sergei Petrunia
397f5cf71e MDEV-27238: Assertion `got_name == named_item_expected()' failed in Json_writer
make_join_select() calls const_cond->val_int(). There are edge cases
where const_cond may have a not-yet optimized subquery.

(The subquery will have used_tables() covered by join->const_tables. It
will still have const_item()==false, so other parts of the optimizer
will not try to evaluate it.  We should probably mark such subqueries
as constant but that is outside the scope of this MDEV)
2021-12-23 14:08:43 +03:00
Dmitry Shulga
fff8ac2e96 MDEV-21866: Assertion `!result' failed in convert_const_to_int upon 2nd execution of PS
Consider the following use case:
MariaDB [test]> CREATE TABLE t1 (field1 BIGINT DEFAULT -1);
MariaDB [test]> CREATE VIEW v1 AS SELECT DISTINCT field1 FROM t1;

Repeated execution of the following query as a Prepared Statement

MariaDB [test]> PREPARE stmt FROM 'SELECT * FROM v1 WHERE field1 <=> NULL';
MariaDB [test]> EXECUTE stmt;

results in a crash for a server built with DEBUG.

MariaDB [test]> EXECUTE stmt;
ERROR 2013 (HY000): Lost connection to MySQL server during query

Assertion failed: (!result), function convert_const_to_int, file item_cmpfunc.cc, line 476.
Abort trap: 6 (core dumped)

The crash inside the function convert_const_to_int() happens by the reason
that the value -1 is stored in an instance of the class Field_longlong
on restoring its original value in the statement
  result= field->store(orig_field_val, TRUE);
that leads to assigning the value 1 to the variable 'result' with subsequent
crash in the DBUG_ASSERT statement following it
  DBUG_ASSERT(!result);

The main matter here is why this assertion failure happens on the second
execution of the prepared statement and doens't on the first one.
On first handling of the statement
  'EXECUTE stmt;'
a temporary table is created for serving the query involving the view 'v1'.
The table is created by the function create_tmp_table() in the following
calls trace: (trace #1)
  JOIN::prepare (at sql_select.cc:725)
    st_select_lex::handle_derived
      LEX::handle_list_of_derived
        TABLE_LIST::handle_derived
          mysql_handle_single_derived
            mysql_derived_prepare
              select_union::create_result_table
                create_tmp_table

Note, that the data member TABLE::status of a TABLE instance returned by the
function create_tmp_table() has the value 0.

Later the function setup_table_map() is called on the TABLE instance just
created for the sake of the temporary table (calls trace #2 is below):
  JOIN::prepare (at sql_select.cc:737)
    setup_tables_and_check_access
      setup_tables
        setup_table_map
where the data member TABLE::status is set to the value STATUS_NO_RECORD.

After that when execution of the method JOIN::prepare reaches calling of
the function setup_without_group() the following calls trace is invoked
  JOIN::prepare
    setup_without_group
      setup_conds
        Item_func::fix_fields
          Item_func_equal::fix_length_and_dec
            Item_bool_rowready_func2::fix_length_and_dec
              Item_func::setup_args_and_comparator
                Item_func::convert_const_compared_to_int_field
                  convert_const_to_int

There is the following code snippet in the function convert_const_to_int()
at the line item_cmpfunc.cc:448
    bool save_field_value= (field_item->const_item() ||
                            !(field->table->status & STATUS_NO_RECORD));
Since field->table->status has bits STATUS_NO_RECORD set the variable
save_field_value is false and therefore neither the method
Field_longlong::val_int() nor the method Field_longlong::store is called
on the Field instance that has the numeric value -1.
That is the reason why first execution of the Prepared Statement for the query
  'SELECT * FROM v1 WHERE field1 <=> NULL'
is successful.

On second running of the statement 'EXECUTE stmt' a new temporary tables
is also created by running the calls trace #1 but the trace #2 is not executed
by the reason that data member SELECT_LEX::first_cond_optimization has been set
to false on first execution of the prepared statemet (in the method
JOIN::optimize_inner()). As a consequence, the data member TABLE::status for
a temporary table just created doesn't have the flags STATUS_NO_RECORD set and
therefore on re-execution of the prepared statement the methods
Field_longlong::val_int() and Field_longlong::store() are called for the field
having the value -1 and the DBUG_ASSERT(!result) is fired.

To fix the issue the data member TABLE::status has to be assigned the value
STATUS_NO_RECORD in every place where the macros empty_record() is called
to emptify a record for just instantiated TABLE object created on behalf
the new temporary table.
2021-12-16 08:48:15 +07:00
Sergei Petrunia
136bcfdf75 MDEV-27270: Wrong query plan with Range Checked for Each Record and ORDER BY ... LIMIT
Followup to fix for MDEV-25858: When test_if_skip_sort_order() decides
to use an index to satisfy ORDER BY ... LIMIT clause, it should
disable "Range Checked for Each Record" optimization.

Do this in all cases.
2021-12-15 22:43:24 +03:00
Sergei Krivonos
ea94895369 MDEV-27206: [ERROR] Duplicated key: cause, Assertion `is_uniq_key' failed with optimizer trace 2021-12-10 22:12:01 +02:00
Marko Mäkelä
978116d991 Merge 10.7 into 10.8 2021-12-10 12:29:14 +02:00
Sergei Golubchik
ef77c05126 Merge branch '10.6' into 10.7 2021-12-08 10:33:36 +01:00
Sergei Golubchik
186c1fa250 Merge branch '10.5' into 10.6 2021-12-07 22:11:30 +01:00
Sergei Golubchik
de70f921ce Merge branch '10.4' into 10.5 2021-12-07 21:30:27 +01:00
Sergei Golubchik
1e8bcbd0a0 Revert "MDEV-27036: re-enable my_json_writer-t unit test"
This reverts commit 2d21917e7d.

No explainations, lots of code moved, wrong cmake changes
2021-12-07 09:57:51 +01:00
Sergei Golubchik
e8a91c18ea Merge branch '10.3' into 10.4 2021-12-07 09:47:42 +01:00
Sergei Golubchik
153b75b576 Merge branch '10.2' into 10.3 2021-12-06 22:23:07 +01:00
Sergei Krivonos
2d21917e7d MDEV-27036: re-enable my_json_writer-t unit test 2021-12-04 22:25:46 -05:00
Igor Babaev
ac963142ee MDEV-26553 NOT IN subquery construct crashing 10.1 and up
This bug was introduced by commit be00e279c6
The commit was applied for the task MDEV-6480 that allowed to remove top
level disjuncts from WHERE conditions if the range optimizer evaluated them
as always equal to FALSE/NULL.
If such disjuncts are removed the WHERE condition may become an AND formula
and if this formula contains multiple equalities the field JOIN::item_equal
must be updated to refer to these equalities. The above mentioned commit
forgot to do this and it could cause crashes for some queries.

Approved by Oleksandr Byelkin <sanja@mariadb.com>
2021-11-26 13:02:39 -08:00
Sergei Krivonos
73df7a3009 MDEV-27036: resolve duplicated key issues of JSON tracing outputs:
MDEV-27036: repeated "table" key resolve for print_explain_json

MDEV-27036: duplicated keys in best_access_path

MDEV-27036: Explain_aggr_filesort::print_json_members: resolve duplicated "filesort" member in Json object

MDEV-27036: Explain_basic_join::
            print_explain_json_interns fixed start_dups_weedout case for main.explain_json test
2021-11-26 15:11:06 +02:00
Marko Mäkelä
5f160b4d86 Merge 10.6 into 10.7 2021-11-25 08:10:02 +02:00
Marko Mäkelä
3cfbfa58de Merge 10.5 into 10.6 2021-11-25 08:08:42 +02:00
Sergei Krivonos
cba065f4fe Json_writer_object add integers 2021-11-24 13:01:49 +02:00
Sergei Krivonos
d4d71153db Json_writer_object add integers 2021-11-19 01:55:23 +02:00
Sergei Golubchik
a398fcbff6 MDEV-26635 ROW_NUMBER is not 0 for errors not caused because of rows 2021-10-26 17:29:40 +02:00
Marko Mäkelä
71d4ecf182 Merge 10.6 into 10.7 2021-10-22 14:41:47 +03: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
Eric Herman
401ff6994d MDEV-26221: DYNAMIC_ARRAY use size_t for sizes
https://jira.mariadb.org/browse/MDEV-26221
my_sys DYNAMIC_ARRAY and DYNAMIC_STRING inconsistancy

The DYNAMIC_STRING uses size_t for sizes, but DYNAMIC_ARRAY used uint.
This patch adjusts DYNAMIC_ARRAY to use size_t like DYNAMIC_STRING.

As the MY_DIR member number_of_files is copied from a DYNAMIC_ARRAY,
this is changed to be size_t.

As MY_TMPDIR members 'cur' and 'max' are copied from a DYNAMIC_ARRAY,
these are also changed to be size_t.

The lists of plugins and stored procedures use DYNAMIC_ARRAY,
but their APIs assume a size of 'uint'; these are unchanged.
2021-10-19 16:00:26 +03:00
Oleksandr Byelkin
27bf57fd6d MDEV-26299: Some views force server (and mysqldump) to generate invalid SQL for their definitions
Do not print illegal table field names for non-top-level SELECT list,
they will not be refered in any case but create problem for parsing
of printed result.
2021-10-18 23:00:15 +02:00
Marko Mäkelä
b4911f5a34 Merge 10.6 into 10.7 2021-10-13 16:37:12 +03:00
Marko Mäkelä
a8379e53e8 Merge 10.5 into 10.6
The changes to galera.galear_var_replicate_myisam_on
in commit d9b933bec6
are omitted due to conflicts
with commit 27d66d644c.
2021-10-13 13:28:12 +03:00
Marko Mäkelä
99bb3fb656 Merge 10.4 into 10.5 2021-10-13 12:33:56 +03:00
Marko Mäkelä
a736a3174a Merge 10.3 into 10.4 2021-10-13 12:03:32 +03:00
Marko Mäkelä
4a7dfda373 Merge 10.2 into 10.3 2021-10-13 11:38:21 +03:00
Aleksey Midenkov
ff77a09bda MDEV-22464 Server crash on UPDATE with nested subquery
Uninitialized ref_pointer_array[] because setup_fields() got empty
fields list.  mysql_multi_update() for some reason does that by
substituting the fields list with empty total_list for the
mysql_select() call (looks like wrong merge since total_list is not
used anywhere else and is always empty). The fix would be to return
back the original fields list. But this fails update_use_source.test
case:

  --error ER_BAD_FIELD_ERROR
  update v1 set t1c1=2 order by 1;

Actually not failing the above seems to be ok.

The other fix would be to keep resolve_in_select_list false (and that
keeps outer context from being resolved in
Item_ref::fix_fields()). This fix is more consistent with how SELECT
behaves:

  --error ER_SUBQUERY_NO_1_ROW
  select a from t1 where a= (select 2 from t1 having (a = 3));

So this patch implements this fix.
2021-10-11 13:36:07 +03:00
Aleksey Midenkov
275e7d23f7 MDEV-14846 InnoDB: assertion on trx->state because of deadlock error ignored
On deadlock transaction is rolled back (and trx->state is cleared) but
SELECT continued the loop because evaluate_join_record() ignored the
error status returned from lower join evaluation. val_int() does not
return error status so it is checked by thd->is_error().

Test case was created by Thirunarayanan Balathandayuthapani
<thiru@mariadb.com>
2021-10-11 12:26:43 +03:00
Marko Mäkelä
2255649939 Merge 10.6 into 10.7 2021-09-17 20:23:17 +03:00
Marko Mäkelä
03c09837fc Merge 10.5 into 10.6 2021-09-16 20:17:12 +03:00
Monty
b4f24c745a Merge branch '10.4' into 10.5
Fixed also an error in suite/perfschema/t/transaction_nested_events-master.opt
2021-09-15 20:23:07 +03:00
Monty
689b8d060a MDEV-23519 Protocol packet - "Original Name" info is showing alias name,
instead of original name of the column

When doing refactoring of temporary table field creation a mistake was
done when copying the column name when creating internal temporary tables.
For internal temporary tables we should use the original field name, not
the item name (= alias).
2021-09-14 20:14:04 +03:00
Sergei Golubchik
0299ec29d4 cleanup: MY_BITMAP mutex
in about a hundred of users of MY_BITMAP, only two were using its
built-in mutex, and only one of those two was actually needing it.

Remove the mutex from MY_BITMAP, remove all associated conditions
and checks in bitmap functions. Use an external LOCK_temp_pool
mutex and temp_pool_set_next/temp_pool_clear_bit acccessors.

Remove bitmap_init/bitmap_free, always use my_* versions.
2021-08-26 23:39:52 +02:00
Marko Mäkelä
ddcb242b3c Merge 10.6 into 10.7 2021-08-04 11:52:39 +03: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
c314fd8c1a compilation failure on clang 11.1.0
returning NULL (a.k.a. nullptr) from a bool function.

followup for add782a13e
2021-07-30 07:51:58 +02:00
Nikita Malyavin
c6bff46958 MDEV-16026 MDEV-16481 refactor Sys_var_vers_asof
MDEV-16026: Forbid global system_versioning_asof in non-default time zone

* store `system_versioning_asof` in unix time;
* both session and global vars are processed in session timezone;
* setting `default` does not copy global variable anymore. Instead, it sets
  system_time to SYSTEM_TIME_UNSPECIFIED, which means that no 'AS OF' time
  is applied and `now()` can be assumed

As a regression, we cannot assign values below 1970 (UTC) anymore

MDEV-16481: set global system_versioning_asof=sf() crashes in specific case

* sys_vars.h: add `MYSQL_TIME` field to `set_var::save_result`
* sys_vars.ic: get rid of calling `var->value->get_date()` from
 `Sys_var_vers_asof::update()`
* versioning.sysvars: add test; remove double warning

refactor Sys_var_vers_asof

* inherit from sys_var rather than Sys_var_enum
* remove junk "DEFAULT" keyword. There is DEFAULT in SQL grammar for it.
* make all conversions in check() to avoid possible errors
* avoid double var->value evaluation, which could
  consequence in undefined behavior
2021-07-27 14:15:01 +03:00
Rucha Deodhar
5518c3209b MDEV-23178: Qualified asterisk not supported in INSERT .. RETURNING
Analysis: When we have INSERT/REPLACE returning with qualified asterisk in the
RETURNING clause, '*' is not resolved properly because of wrong context.
context->table_list is NULL or has incorrect table because context->table_list
has tables from the FROM clause. For INSERT/REPLACE...SELECT...RETURNING,
context->table_list has table we are inserting from. While in other
INSERT/REPLACE syntax, context->table_list is NULL because there is no FROM
clause.
Fix: If filling fields instead of '*' for qualified asterisk in RETURNING,
use first_name_resolution_table for correct resolution of item.
2021-07-22 21:56:18 +05:30