1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-18 23:03:28 +03:00
Commit Graph

1970 Commits

Author SHA1 Message Date
e7701f8db2 Merge branch '10.2' into 10.3 2021-05-04 17:32:29 +02:00
a20195bba5 MDEV-21603 Crashing SHOW TABLES with derived table in WHERE condition
When you only need view structure, don't call handle_derived with
DT_CREATE and rely on its internal hackish check to skip DT_CREATE.
Because handle_derived is called from many different places,
and this internal hackish check is indiscriminative.

Instead, just don't ask handle_derived to do DT_CREATE
if you don't want it to do DT_CREATE.
2021-05-04 16:55:45 +02:00
a8a925dd22 Merge branch bb-10.2-release into bb-10.3-release 2021-05-04 14:49:31 +03:00
5ad7f52558 MDEV-21603 Crashing SHOW TABLES with derived table in WHERE condition
When you only need view structure, don't call handle_derived with
DT_CREATE and rely on its internal hackish check to skip DT_CREATE.
Because handle_derived is called from many different places,
and this internal hackish check is indiscriminative.

Instead, just don't ask handle_derived to do DT_CREATE
if you don't want it to do DT_CREATE.
2021-05-04 09:01:55 +02:00
91599701d0 Bug#29363867: LOST CONNECTION TO MYSQL SERVER DURING QUERY
plugin variables in SET  only locked the plugin till the end of the
statement. If SET with a plugin variable was prepared, it was possible
to uninstall the plugin before EXECUTE. Then EXECUTE would crash,
trying to resolve a now-invalid pointer to a disappeared variable.

Fix: keep plugins locked until the prepared statement is closed.
2021-04-27 18:21:01 +02:00
6c3e860cbf Merge 10.4 into 10.5 2021-04-14 11:35:39 +03:00
61f84bba60 MDEV-25197: The statement set password=password('') executed in PS mode fails in case it is run by a user with expired password
A user connected to a server with an expired password
can't change password with the statement "SET password=..."
if this statement is run in PS mode. In mentioned use case a user
gets the error ER_MUST_CHANGE_PASSWORD on attempt to run
the statement  PREPARE stmt FOR "SET password=...";

The reason of failure to reset password by a locked user using the
statement PREPARE stmt FOR "SET password=..." is that PS-related
statements are not listed among the commands allowed for execution
by a user with expired password. However, simple adding of PS-related
statements (PREPARE FOR/EXECUTE/DEALLOCATE PREPARE ) to the list of
statements allowed for execution by a locked user is not enough
to solve problems, since it opens the opportunity for a locked user
to execute any statement in the PS mode.

To exclude this opportunity, additional checking that the statement
being prepared for execution in PS-mode is the SET statement has to be added.
This extra checking has been added by this patch into the method
Prepared_statement::prepared() that executed on preparing any statement
for execution in PS-mode.
2021-04-13 09:38:32 +07:00
8e2d69f7b8 Fixed access to undefined memory
alloc_query() is examined the content of it's argument, which was
uninitalized.
Fixed by storing stmt_id in llbuf, according to code comments.
2021-03-28 18:43:14 +03:00
d902b53cfe Fixed wrong usage strlen(), should be sizeof()
Found by running valgrind on mtr tests
2021-03-22 17:54:29 +02:00
10d544aa7b Merge 10.4 into 10.5 2021-03-05 12:54:43 +02:00
8bab5bb332 Merge 10.3 into 10.4 2021-03-05 10:36:51 +02:00
ddbc612692 Merge 10.2 into 10.3 2021-03-03 09:41:50 +02:00
259e5243fa MDEV-24860: Incorrect behaviour of SET STATEMENT in case it is executed as a prepared statement
Running statements with SET STATEMENT FOR clause is handled incorrectly in
case the whole statement is executed in prepared statement mode.
For example, running of the following statement
  SET STATEMENT sql_mode = 'NO_ENGINE_SUBSTITUTION' FOR CREATE TABLE t1 AS SELECT CONCAT('abc') AS c1;
results in different definition of the table t1 depending on whether
the statement is executed as a prepared or as a regular statement.

In first case the column c1 is defined as
  `c1` varchar(3) DEFAULT NULL
in the last case the column c1 is defined as
  `c1` varchar(3) NOT NULL

Different definition for the column c1 arise due to the fact that
a value of the data memeber Item_func_concat::maybe_null depends on
whether strict mode is on or off. Below is definition of the method
fix_fields() of the class Item_str_func that is base class for the
class Item_func_concat that is created on parsing the
SET STATEMENT FOR clause.

bool Item_str_func::fix_fields(THD *thd, Item **ref)
{
  bool res= Item_func::fix_fields(thd, ref);
  /*
    In Item_str_func::check_well_formed_result() we may set null_value
    flag on the same condition as in test() below.
  */
  maybe_null= maybe_null || thd->is_strict_mode();
  return res;
}

Although the clause SET STATEMENT sql_mode = 'NO_ENGINE_SUBSTITUTION' FOR
is parsed on PREPARE phase during processing of the prepared statement,
real setting of the sql_mode system variable is done on EXECUTION phase.
On the other hand, the method Item_str_func::fix_fields is called on PREPARE
phase. In result, thd->is_strict_mode() returns true during calling the method
Item_str_func::fix_fields(), the data member maybe_null is assigned the value
true and column c1 is defined as DEFAULT NULL.

To fix the issue the system variables listed in the SET STATEMENT FOR clause
are set at the beginning of handling the PREPARE phase just right before
calling  the function check_prepared_statement() and their original values
restored immediate after return from this function.

Additionally, to avoid code duplication the source code used in the function
mysql_execute_command for setting variables, specified by SET STATEMENT
clause, were extracted to the standalone functions
run_set_statement_if_requested(). This new function is called from
the function  mysql_execute_command() and the method
Prepared_statement::prepare().
2021-02-25 14:36:09 +07:00
25d9d2e37f Merge branch 'bb-10.4-release' into bb-10.5-release 2021-02-15 16:43:15 +01:00
00a313ecf3 Merge branch 'bb-10.3-release' into bb-10.4-release
Note, the fix for "MDEV-23328 Server hang due to Galera lock conflict resolution"
was null-merged. 10.4 version of the fix is coming up separately
2021-02-12 17:44:22 +01:00
60ea09eae6 Merge branch '10.2' into 10.3 2021-02-01 13:49:33 +01:00
9e4a5a81fc MDEV-24208 SHOW RELAYLOG EVENTS command is not supported in the prepared statement protocol yet
Added sending of metadata in response to preparing request for
the commands SQLCOM_SHOW_BINLOG_EVENTS, SQLCOM_SHOW_RELAYLOG_EVENTS
2021-01-13 16:16:13 +07:00
8de233af81 Merge 10.4 into 10.5 2021-01-11 16:29:51 +02:00
fd5e103aa4 Merge 10.3 into 10.4 2021-01-11 10:35:06 +02:00
5a1a714187 Merge 10.2 into 10.3 (except MDEV-17556)
The fix of MDEV-17556 (commit e25623e78a
and commit 61a362c949) has been
omitted due to conflicts and will have to be applied separately later.
2021-01-11 09:41:54 +02:00
cd1e5d65c6 MDEV-19838 fixup: clang -Wunused-const-variable 2021-01-08 08:10:18 +02:00
6a1e655cb0 Merge 10.4 into 10.5 2020-12-02 18:29:49 +02:00
589cf8dbf3 Merge 10.3 into 10.4 2020-12-01 19:51:14 +02:00
81ab9ea63f Merge 10.2 into 10.3 2020-12-01 14:55:46 +02:00
828471cbf8 MDEV 15532 Assertion `!log->same_pk' failed in row_log_table_apply_delete
The reason for the failure is that
thd->mdl_context.release_transactional_locks()
was called after commit & rollback even in cases where the current
transaction is still active.

For 10.2, 10.3 and 10.4 the fix is simple:
- Replace all calls to thd->mdl_context.release_transactional_locks() with
  thd->release_transactional_locks(). The thd function will only call
  the mdl_context function if there are no active transactional locks.
  In 10.6 we will better fix where we will change the return value for
  some trans_xxx() functions to indicate if transaction did close the
  transaction or not. This will avoid the need of the indirect call.

Other things:
- trans_xa_commit() and trans_xa_rollback() will automatically
  call release_transactional_locks() if the transaction is closed.
- We can't do that for the other functions as the caller of many of these
  are doing additional work (like close_thread_tables) before calling
  release_transactional_locks().
- Added missing abort_result_set() and missing DBUG_RETURN in
  select_create::send_eof()
- Fixed wrong indentation in injector::transaction::commit()
2020-11-30 22:21:43 +02:00
b4a5ad8db5 Merge mariadb-10.5.8 into 10.5 2020-11-11 17:42:23 +02:00
99a9774754 Merge mariadb-10.4.17 into 10.4 2020-11-11 17:26:51 +02:00
7da6353b15 Merge branch '10.4' into 10.5 2020-11-10 14:09:05 +01:00
5fbfdae130 Merge branch '10.3' into 10.4 2020-11-10 11:24:13 +01:00
212d92ad26 Merge branch '10.2' into 10.3 2020-11-09 23:32:49 +01:00
19a847d40c MDEV-19838: followup to make happy following protocol implementations:
- mysqlnd from PHP < 7.3
- mysql-connector-python any version
- mysql-connector-java any version

Relaxed check about garbage at the end of the packet in case of no parameters.
Added check for array binding.
Fixed test according to the new paradigm (allow junk at the end of the packet)
2020-11-05 18:59:00 +01:00
133b4b46fe Merge 10.4 into 10.5 2020-11-03 16:24:47 +02:00
533a13af06 Merge 10.3 into 10.4 2020-11-03 14:49:17 +02:00
4489b66afb MDEV-23872 Crash in galera::TrxHandle::state()
Prepared statements which were run over binary protocol crashed
a server if the statement did not have CF_PS_ARRAY_BINDING_OPTIMIZED
flag and the statement was executed in bulk mode and a BF abort occrurred.
This was because the bulk execution resulted in several statements without
calling wsrep_after_statement() between, which confused wsrep transaction
state tracking.

As a fix, call wsrep_after_statement() in bulk loop after each execution
if CF_PS_ARRAY_BINDING_OPTIMIZED is not set.

Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2020-11-03 09:11:04 +02:00
8e1e2856f2 Merge branch '10.4' into 10.5 2020-11-01 14:26:15 +01:00
80c951ce28 Merge branch '10.3' into 10.4 2020-10-31 21:06:49 +01:00
794f665139 Merge branch '10.2' into 10.3 2020-10-30 17:23:53 +01:00
a90b15837c MDEV-19838: fix of error messages 2020-10-29 22:20:21 +01:00
4b854d4795 MDEV-19838 Wrong direxec param data caused crash
In case of direct execution(stmtid=-1, mariadb_stmt_execute_direct in C
API) application is in control of how many parameters client sends to
the server. In case this number is not equal to actual query parameters
number, the server may start to interprete packet data incorrectly, e.g.
starting from the size of null bitmap. And that could cause it to crash
at some point. The commit introduces some additional COM_STMT_EXECUTE
packet sanity checks:
- checking that "types sent" byte is set, and the value is equal to 1.
  if it's not direct execution, then that value is 0 or 1.
- checking that parameter type value is a valid type, and parameter
  flags value is 0 or only "unsigned" bit is set
- added more checks that read does not go beyond the end of the packet
2020-10-29 08:04:32 +01:00
1657b7a583 Merge 10.4 to 10.5 2020-10-22 17:08:49 +03:00
46957a6a77 Merge 10.3 into 10.4 2020-10-22 13:27:18 +03:00
e3d692aa09 Merge 10.2 into 10.3 2020-10-22 08:26:28 +03:00
71d263a198 MDEV-23691 S3 storage engine: delayed slave can drop the table
This commit fixed the problems with S3 after the "DROP TABLE FORCE" changes.
It also fixes all failing replication S3 tests.

A slave is delayed if it is trying to execute replicated queries on a
table that is already converted to S3 by the master later in the binlog.

Fixes for replication events on S3 tables for delayed slaves:
- INSERT and INSERT ... SELECT and CREATE TABLE are ignored but written
  to the binary log.   UPDATE & DELETE will be fixed in a future commit.

Other things:
- On slaves with --s3-slave-ignore-updates set, allow S3 tables to be
  opened in read-write mode. This was done to be able to
  ignore-but-replicate queries like insert.  Without this change any
  open of an S3 table failed with 'Table is read only' which is too
  early to be able to replicate the original query.
- Errors are now printed if handler::extra() call fails in
  wait_while_tables_are_used().
- Error message for row changes are changed from HA_ERR_WRONG_COMMAND
  to HA_ERR_TABLE_READONLY.
- Disable some maria_extra() calls for S3 tables. This could cause
  S3 tables to fail in some cases.
- Added missing thr_lock_delete() to ma_open() in case of failure.
- Removed from mysql_prepare_insert() the not needed argument 'table'.
2020-10-21 03:09:29 +03:00
24c5af6758 Fix the constants names 2020-10-15 12:56:06 +02:00
0ccdf8b11b MDEV-19275 Provide SQL service to plugins.
test_sql_service plugin added and employed in test_sql_service.test.
2020-10-02 10:19:00 +04:00
b01c426146 MDEV-19275 Provide SQL service to plugins.
Protocol_local fixed so it can be used now.
Some Protocol:: methods made virtual so they can adapt.
as well as net_ok and net_send_error functions.
execute_sql_string function is exported to the plugins.
To be changed with the mysql_use_result.
2020-08-14 21:04:25 +04:00
c55f24cd99 MDEV-23162 Improve Protocol performance for numeric data
An alternative implementation (replacing the one based on repertoire).

This implementation makes Field send itself to Protocol_text using
data type specific Protocol methods rather than field->val_str()
followed by protocol_text->store_str().

As now Field sends itself in the same way to all protocol types
(e.g. Protocol_binary, Protocol_text, Protocol_local),
the method Field::send_binary() was renamed just to Field::send().

Note, this change introduces symmetry between Field and Item,
because Items also send themself using a single method Item::send(),
which is used for *all* protocol types.

Performance improvement is achieved by the fact that Protocol_text
implements these data type specific methods using store_numeric_string_aux()
rather than store_string_aux(). The conversion now happens only when
character_set_results is not ASCII compatible character sets
(e.g. UCS2, UTF16, UTF32).

In the old code (before any MDEV-23162 work, e.g. as of 10.5.4),
Protocol_text::store(Field*) used val_str() for all data types.
So the execution went through the character set conversion routines
even for numeric and temporal data types.

Benchmarking summary (see  details in MDEV-23478):

The new approach stably demonstrates additional improvement comparing
to the previous implementation (the smaller time - the better):

Original   - the commit before MDEV-23162
             be98036f25

        1m9.336s
        1m9.290s
        1m9.300s

MDEV-23162 - the repertoire optimization

        1m6.101s
        1m5.988s
        1m6.264s

MDEV-23478 - this commit

        1m2.150s
        1m2.079s
        1m2.099s
2020-08-14 10:07:03 +04:00
f1a9700fec Revert "MDEV-23162 Improve Protocol performance for numeric data"
This reverts commit eb2eaba7fd.

A different implementation of MDEV-23162 is coming.
2020-08-14 09:14:07 +04:00
e96f66b93d MDEV-23270 Remove a String parameter from Protocol::store(double/float) 2020-08-14 09:14:07 +04:00
50a11f396a Merge 10.4 into 10.5 2020-08-01 14:42:51 +03:00