Commit graph

74595 commits

Author SHA1 Message Date
Daniel Black
3a62ff7e89 Revert "MDEV-25343 add read secret size in file key plugin"
This reverts commit cee7175b79.
2022-10-19 20:05:59 +11:00
kurt
cee7175b79 MDEV-25343 add read secret size in file key plugin 2022-10-19 16:44:16 +11:00
Daniel Black
8c38939369 MDEV-29540 Incorrect sequence values in INSERT SELECT
The population of default values in INSERT SELECT was being
performed twice. With sequences, this resulted in every
second sequence value being used.

With SELECT INSERT we remove the second invokation of
table->update_default_fields(). This was already performed
in store_values() invoking fill_record_n_invoke_before_triggers()
which invoked update_default_fields() previously.

We do need to return an error on duplicate values, so the
::store_values is extended to take the ignore option.
2022-10-19 08:15:42 +11:00
Anel Husakovic
64f822c142 MDEV-28455: CREATE TEMPORARY TABLES privilege is insufficient for SHOW COLUMNS
=========== Problem =============
- `show columns` is not working for temporary tables, even though there
is enough privilege `create temporary tables`.
=========== Solution =============
- Append `TMP_TABLE_ACLS` privilege when running `show columns` for temp
tables.
- Additionally `check_access()` for database only once, not for each
field
=========== Additionally =============
- Update comments for function `check_table_access` arguments

Reviewed by: <vicentiu@mariadb.org>
2022-10-18 10:25:55 +03:00
Dmitry Shulga
bd9274faa4 MDEV-16128: Server crash in Item_func::print_op on 2nd execution of PS
For some queries that involve tables with different but convertible
character sets for columns taking part in the query, repeatable
execution of such queries in PS mode or as part of a stored routine
would result in server abnormal termination.

For example,
  CREATE TABLE t1 (a2 varchar(10));
  CREATE TABLE t2 (u1 varchar(10) CHARACTER SET utf8);
  CREATE TABLE t3 (u2 varchar(10) CHARACTER SET utf8);
  PREPARE stmt FROM
    "SELECT t1.* FROM (t1 JOIN t2 ON (t2.u1 = t1.a2))
     WHERE (EXISTS (SELECT 1 FROM t3 WHERE t3.u2 = t1.a2))";

  EXECUTE stmt;
  EXECUTE stmt; <== Running this prepared statement the second time
                    results in server crash.

The reason of server crash is that an instance of the class
Item_func_conv_charset, that created for conversion of a column
from one character set to another, is allocated on execution
memory root but pointer to this instance is stored in an item
placed on prepared statement memory root. Below is calls trace to
the place where an instance of the class Item_func_conv_charset
is created.

setup_conds
 Item_func::fix_fields
  Item_bool_rowready_func2::fix_length_and_dec
   Item_func::setup_args_and_comparator
    Item_func_or_sum::agg_arg_charsets_for_comparison
     Item_func_or_sum::agg_arg_charsets
      Item_func_or_sum::agg_item_set_converter
       Item::safe_charset_converter

And the following trace shows the place where a pointer to
the instance of the class Item_func_conv_charset is passed
to the class Item_func_eq, that is created on a memory root of
the prepared statement.

Prepared_statement::execute
 mysql_execute_command
  execute_sqlcom_select
   handle_select
    mysql_select
     JOIN::optimize
      JOIN::optimize_inner
       convert_join_subqueries_to_semijoins
        convert_subq_to_sj

To fix the issue, switch to the Prepared Statement memory root
before calling the method Item_func::setup_args_and_comparator
in order to place any created Items on permanent memory root.
It may seem that such approach would result in a memory
leakage in case the parameter marker '?' is used in the query
as in the following example
  PREPARE stmt FROM
    "SELECT t1.* FROM (t1 JOIN t2 ON (t2.u1 = t1.a2))
     WHERE (EXISTS (SELECT 1 FROM t3 WHERE t3.u2 = ?))";
  EXECUTE stmt USING convert('A' using latin1);
but it wouldn't since for such case any of the parameter markers
is treated as a constant and no subquery to semijoin optimization
is performed.
2022-10-17 15:05:17 +07:00
Sergei Golubchik
e0b4db5ba3 MDEV-29750 triggers can modify history
should be the same behavior as for virtual columns:
* a warning on every inserted row
* silently ignored in a trigger
2022-10-16 01:24:30 +02:00
Oleksandr Byelkin
291872ec82 Merge branch '10.3' into 10.4 2022-10-14 10:26:22 +02:00
Oleksandr Byelkin
7cad2e94b1 Merge branch 'bb-10.4-vp-MDEV-27691' into 10.4 2022-10-14 09:04:54 +02:00
Oleksandr Byelkin
89e3815b39 Merge branch 'bb-10.3-vp-MDEV-27691' into 10.3 2022-10-14 08:29:11 +02:00
Marko Mäkelä
f404911557 Merge 10.3 into 10.4 2022-10-13 16:50:26 +03:00
Nikita Malyavin
128356b4b1 MDEV-29753 An error is wrongly reported during INSERT with vcol index
See also commits aa8a31da and 64678c for a Bug  fix.

In this scenario INSERT chose to check if delete unmarking is available for
a just deleted record. To build an update vector, it needed to calculate
the vcols as well. Since this INSERT was not IGNORE-flagged, recalculation
failed.

Solutiuon: temporarily set abort_on_warning=true, while calculating the
column for delete-unmarked insert.
2022-10-12 20:49:45 +03:00
Nikita Malyavin
3cd2c1e8b6 MDEV-29299 SELECT from table with vcol index reports warning
As of now innodb does not store trx_id for each record in secondary index.
The idea behind is following: let us store only per-page max_trx_id, and
delete-mark the records when they are deleted/updated.

If the read starts, it rememders the lowest id of currently active
transaction. Innodb refers to it as trx->read_view->m_up_limit_id.
See also ReadView::open.

When the page is fetched, its max_trx_id is compared to m_up_limit_id.
If the value is lower, and the secondary index record is not delete-marked,
then this page is just safe to read as is. Else, a clustered index could be
needed ato access. See page_get_max_trx_id call in row_search_mvcc, and the
corresponding switch (row_search_idx_cond_check(...)) below.

Virtual columns are required to be updated in case if the record was
delete-marked. The motivation behind it is documented in
Row_sel_get_clust_rec_for_mysql::operator() near
row_sel_sec_rec_is_for_clust_rec call.

This was basically a description why virtual column computation can
normally happen during SELECT, and, generally, a vcol index access.

Sometimes stats tables are updated by innodb. This starts a new
transaction, and it can happen that it didn't finish to the moment of
SELECT execution, forcing virtual columns recomputation. If the result was
a something that normally outputs a warning, like division by zero, then
it could be outputted in a racy manner.

The solution is to suppress the warnings when a column is computed
for the described purpose.
ignore_wrnings argument is added innobase_get_computed_value.
Currently, it is only true for a call from
row_sel_sec_rec_is_for_clust_rec.
2022-10-12 20:49:45 +03:00
Sergei Golubchik
2aab7f2d0a MDEV-26597 post-fix: cannot add new error messages in 10.4
followup for e8acec8974
2022-10-11 16:20:22 +02:00
Marko Mäkelä
7434eb566e Merge 10.3 into 10.4 2022-10-11 15:18:49 +03:00
Marko Mäkelä
e8101a4d03 MDEV-19455/MDEV-29342 fixup: Avoid DEBUG_DBUG=-d,... 2022-10-11 13:56:47 +03:00
Julius Goryavsky
c49ebd2622 MDEV-21905: Galera test galera_var_notify_cmd causes hang
The problem is related to performing operations without switching
wsrep off, this commit fixes this and allows disabled tests.
2022-10-11 10:15:09 +02:00
Julius Goryavsky
3f5b03c415 MDEV-21905: Galera test galera_var_notify_cmd causes hang
The problem is related to performing operations without switching
wsrep off, this commit fixes this and allows disabled tests.
2022-10-11 08:37:13 +02:00
Alexander Barkov
3416315407 A followup for MDEV-29672 Add MTR tests covering key and key segment flags and types
Adding debug output for key and keyseg flags at ha_myisam::open() time.
So now there are three points of debug output:

1. In the very end of mysql_prepare_create_table()
2. In ha_myisam::create(), after the table2myisam() call
3. In ha_myisan::open(), after the mi_open() call

mi_create(), which is is called between 2 and 3, modifies flags for
some data types, so the output in 2 and 3 is different.
2022-10-10 14:10:48 +04:00
Marko Mäkelä
56b97ca03a MDEV-29742 heap number overflow
A previous fix in commit efd8af535a
failed to cover ALTER TABLE.

PageBulk::isSpaceAvailable(): Check for record heap number overflow.
2022-10-10 09:12:55 +03:00
Jan Lindström
0908a049f8 MDEV-25389 : Assertion `!is_thread_specific || (mysqld_server_initialized && thd)' failed in void my_malloc_size_cb_func(long long int, my_bool)
If wsrep slave thread creation fails for some reason we need to handle
this error correctly and set actual running slave threads accordingly.
2022-10-09 10:09:47 +03:00
Jan Lindström
e8acec8974 MDEV-26597 : Assertion `!wsrep_has_changes(thd) || (thd->lex->sql_command == SQLCOM_CREATE_TABLE && !thd->is_current_stmt_binlog_format_row())' failed.
If repl.max_ws_size is set too low following CREATE TABLE could fail
during commit. In this case wsrep_commit_empty should allow rolling
it back if provider state is s_aborted.

Furhermore, original ER_ERROR_DURING_COMMIT does not really tell anything
clear for user. Therefore, this commit adds a new error
ER_TOO_BIG_WRITESET. This will change some test cases output.
2022-10-09 10:09:47 +03:00
Jan Lindström
ab3ec013c4 MDEV-27123 : auto_increment_increment and auto_increment_offset reset to 1 in current session after alter table on auto-increment column
Problem was that in ALTER TABLE execution variables were set
to 1 even when wsrep_auto_increment_control is OFF. We should
set them only when wsrep_auto_increment_control is ON.
2022-10-09 10:09:47 +03:00
Jan Lindström
7be82a1fec MDEV-29142 : Assertion `!_current_thd()' failed in void destroy_background_thd(THD*)
In test user has set WSREP_ON=OFF this causes streaming replication
recovery to fail and this caused call to unireg_abort(). However,
this call is not necessary and we can let transaction to fail. Naturally,
if real user does this he needs to bootstrap his cluster.
2022-10-09 10:09:47 +03:00
Sergei Golubchik
5f26f50020 typo fixed, followup for 3fe55fa8be 2022-10-07 15:24:02 +02:00
Sergei Golubchik
3fe55fa8be CREATE ... VALUES ... didn't require INSERT privilege 2022-10-07 14:41:03 +02:00
Aleksey Midenkov
37a86b933e Merge 10.3 into 10.4 2022-10-06 23:37:42 +03:00
Jan Lindström
d099bcadc3 Test results updated. 2022-10-06 13:08:20 +03:00
Jan Lindström
09f7889b5c MDEV-29706 : SIGSEGV in wsrep_TOI_begin on non-Galera builds
Do not allow setting wsrep_on=ON if no provider is set.
2022-10-06 13:08:20 +03:00
Marko Mäkelä
3708bef606 MDEV-27682: Temporarily disable a failing test 2022-10-06 07:40:00 +03:00
Marko Mäkelä
ba9ade47e3 MDEV-29710: Skip main.update_use_source on Valgrind
This test is not slow, but it reliably produces an EXPLAIN difference
(number of rows) on the Valgrind builder. A possible explanation could be
that the purge threads are not being scheduled. Valgrind runs all threads
in a single thread.
2022-10-06 07:38:46 +03:00
Marko Mäkelä
f600690c6b MDEV-29710: Skip some more tests on Valgrind 2022-10-05 20:37:54 +03:00
Marko Mäkelä
65d0c57c1a Merge 10.3 into 10.4 2022-10-05 20:30:57 +03:00
Aleksey Midenkov
074e358213 MDEV-29697 Assertion failure in Diagnostics_area::set_ok_status
upon CREATE OR REPLACE causing ER_UPDATE_TABLE_USED

Missed set return status to 1.
2022-10-05 19:53:13 +03:00
Aleksey Midenkov
0779e2cb10 MDEV-28576 RENAME COLUMN with NOCOPY algorithm leads to corrupt partitioned table
When f.ex. table is partitioned by HASH(a) and we rename column `a' to
`b' partitioning filter stays unchanged: HASH(a). That's the wrong
behavior.

The patch updates partitioning filter in accordance to the new columns
names. That includes partition/subpartition expression and
partition/subpartition field list.
2022-10-05 19:53:13 +03:00
Marko Mäkelä
111cbdf3da MDEV-29710: Valgrind tests massively fail due to silently killing server on shutdown timeout
Let us disable Valgrind on tests that would fail because a
server shutdown or a STOP SLAVE command would take longer,
causing the test harness to forcibly and silently kill the server
due to an exceeded timeout.
2022-10-05 15:18:58 +03:00
Marko Mäkelä
e0bcff10ef MDEV-29710: Disable main.log_slow under Valgrind
Under Valgrind, this test may occasionally fail because the sleep-based
timeouts of less than 1 second could be exceeded.
2022-10-05 15:18:44 +03:00
Marko Mäkelä
380e06f84b MDEV-29710: Disable sys_vars.innodb_flush_method_func under Valgrind
The test could emit some I/O error when run under Valgrind.
2022-10-05 15:16:03 +03:00
Marko Mäkelä
c64e2d60a3 MDEV-29710: Disable innodb.table_flags under Valgrind 2022-10-05 15:15:28 +03:00
Marko Mäkelä
1562b2c20b MDEV-29666 InnoDB fails to purge secondary index records when indexed virtual columns exist
row_purge_get_partial(): Replaces trx_undo_rec_get_partial_row().
Also copy the purge_node_t::ref to the purge_node_t::row.
In this way, the clustered index key fields will always be
available, even if thanks to
commit d384ead0f0 (MDEV-14799)
they would no longer be repeated in the remaining part of the
undo log record.
2022-10-05 09:30:33 +03:00
Julius Goryavsky
19f0b96d53 MDEV-27682: bundled wsrep_notify.sh causes mariadbd to freeze during start
This commit adds automation that will reduce the possibility
of user errors when customizing wsrep_notify.sh (in particular
caused by user-specified parameters). Now all leading and trailing
spaces are removed from the user-specified parameters and automatic
port and host address substitution has been added to scripts, as
well as automatic password substitution to the client command line,
only if it is specified in the wsrep_notify.sh and not as empty
strings. Also added support for automatic substitution of the all
SSL-related parameters and improved parsing for ipv6 addresses
(to allow "[...]" notation for ipv6 addresses). Also added a
test to check if the wsrep notify script will works with SSL.
2022-10-04 13:16:17 +02:00
Monty
d1bc469dca Disable valgrind for test in main that takes > 200 seconds
One can run these with --valgrind --big
2022-10-04 11:59:01 +03:00
Sergei Golubchik
d4f6d2f08f Merge branch '10.3' into 10.4 2022-10-01 23:07:26 +02:00
Oleksandr Byelkin
f65ba9aeb7 MDEV-17124: mariadb 10.1.34, views and prepared statements: ERROR 1615 (HY000): Prepared statement needs to be re-prepared
The problem is that if table definition cache (TDC) is full of real tables
which are in tables cache, view definition can not stay there so will be
removed by its own underlying tables.
In situation above old mechanism of detection matching definition in PS
and current version always require reprepare and so prevent executing
the PS.

One work around is to increase TDC, other - improve version check for
views/triggers (which is done here). Now in suspicious cases we check:
 - timestamp (microseconds) of the view to be sure that version really
   have changed;
 - time (microseconds) of creation of a trigger related to time
   (microseconds) of statement preparation.
2022-09-30 12:11:37 +02:00
Alexander Barkov
1118e979c2 MDEV-29672 Add MTR tests covering key and key segment flags and types 2022-09-30 11:08:49 +04:00
Anel Husakovic
1f51d6c0f6 MDEV-28548: ER_TABLEACCESS_DENIED_ERROR is missing information about DB
- Added missing information about database of corresponding table for various types of commands
- Update some typos

- Reviewed by: <vicentiu@mariadb.org>
2022-09-30 08:48:57 +02:00
Sergei Golubchik
f9605eb209 fix sporadic failures on main.kill
KILL QUERY ID 0 was sometimes finding con3 that was still in the process
of disconnecting and had query_id==0 (as it didn't run any queries)
2022-09-29 10:18:50 +02:00
Igor Babaev
28ae361857 MDEV-29361 Infinite recursive calls when detecting CTE dependencies
This patch resolves the problem of improper name resolution of table
references to embedded CTEs for some queries. This improper binding could
lead to
  - infinite sequence of calls of recursive functions
  - crashes due to resolution of null pointers
  - wrong result sets returned by queries
  - bogus error messages

If the definition of a CTE contains with clauses then such CTE is called
embedding CTE while CTEs from the with clauses are called embedded CTEs.
If a table reference used in the definition of an embedded CTE cannot be
resolved within the unit that contains this reference it still may be
resolved against a CTE definition from the with clause with one of the
embedding CTEs.
A table reference can be resolved against a CTE definition if it used in
the the scope of this definition and it refers to the name of the CTE.
Table reference t is in the scope of the CTE definition of CTE cte if
- the definition of cte is an element of a with clause declared as
  RECURSIVE and the reference t belongs either to the unit to which
  this with clause is attached or to one of the elements of this clause
- the definition of cte is an element of a with clause without RECURSIVE
  specifier and the reference t belongs either to the unit to which this
  with clause is attached or to one of the elements from this clause that
  are placed before the definition of cte.
If a table reference can be resolved against several CTE definitions then
it is bound to the most embedded.

The code before this patch not always resolved table references used in
embedded CTE according to the above rules.

Approved by Oleksandr Byelkin <sanja@mariadb.com>
2022-09-28 22:33:05 -07:00
Alexey Botchkov
b2cfcf1d1f MDEV-21134 Crash with partitioned table, PARTITION syntax, and index_merge.
When the partition table is cloned, the handlers for the partitions that were not opened
should anyway be created (but not opened).
2022-09-27 15:27:34 +04:00
Oleksandr Byelkin
47e9678982 MDEV-29022 add_slave destroy child list and has dead code
Nowdays subquery in a UNION's ORDER BY placed correctly in fake select,
the only problem was incorrect Name_resolution_contect is fixed by this
patch in parsing, so we do not need scanning/reseting of ORDER BY of
a union.
2022-09-27 09:56:21 +02:00
Sergei Golubchik
fa4e84b5d9 cleanup: main.mysqldump test
show error messages from mysqldump/mysqlimport
2022-09-26 15:01:36 +02:00