mysql_prepare_alter_table(): Alter table should check whether
foreign key exists when it expected to exists and
report the error in early stage
dict_foreign_parse_drop_constraints(): Don't throw error if the
foreign key constraints doesn't exist when if exists is given
in the statement.
move MYSQL::fields down, replacing MYSQL::unused5
this way only MYSQL::fields and MYSQL::field_alloc will still have
different offset in C/C and the server, but all other MYSQL members
will get back in sync.
luckily, plugins shouldn't need MYSQL::fields or MYSQL::field_alloc
added a check to ensure both MYSQL structures are always of
the same size.
After successful connection, server always sets SERVER_STATUS_AUTOCOMMIT
in server_status in the OK packet. This is wrong, if global variable
autocommit=0.
Fixed THD::init(), added mysql_client_test test.
Thanks to Diego Dupin for the providing the patch.
Signed-off-by: Vladislav Vaintroub <vvaintroub@gmail.com>
This bug was caused by a patch for the task MDEV-32733.
Incorrect memory root was used for allocation of memory
pointed by the data memebr Item_func_json_contains_path::p_found.
Let us make the test compatible with ./mtr --repeat
and convert variable_value to integer, so that comparisons like
16>9 will work as intended, instead of being compared as '16'<'9'.
The bug is fixed by the patch ported from MySQL. See the comprehensive
description below.
commit 455c4e8810c76430719b1a08a63ca0f69f44678a
Author: Guilhem Bichot <guilhem.bichot@oracle.com>
Date: Fri Mar 13 17:51:27 2015 +0100
Bug#17668844: CRASH/ASSERT AT ITEM_TYPE_HOLDER::VAL_STR IN ITEM.C
We have a predicate of the form:
literal_row <=> (a UNION)
The subquery is constant, so Item_cache objects are used for its
SELECT list.
In order, this happens:
- Item_subselect::fix_fields() calls select_lex_unit::prepare,
where we create Item_type_holder's
(appended to unit->types list), create the tmp table (using type info
found in unit->types), and call fill_item_list() to put the
Item_field's of this table into unit->item_list.
- Item_subselect::fix_length_and_dec() calls set_row() which
makes Item_cache's of the subquery wrap the Item_type_holder's
- When/if a first result row is found for the subquery,
Item_cache's are re-pointed to unit->item_list
(i.e. Item_field objects which reference the UNION's tmp table
columns) (see call to Item_singlerow_subselect::store()).
- In our subquery, no result row is found, so the Item_cache's
still wrap Item_type_holder's; evaluating '<=>' reads the
value of those, but Item_type_holder objects are not expected to be
evaluated.
Fix: instead of putting unit->types into Item_cache, and later
replacing with unit->item_list, put unit->item_list in Item_cache from
the start.
Approved by Oleksandr Byelkin <sanja@mariadb.com>
This is the follow-up patch that removes explicit use of thd->stmt_arena
for memory allocation and replaces it with call of the method
THD::active_stmt_arena_to_use()
Additionally, this patch adds extra DBUG_ASSERT to check that right
query arena is in use.
This patch is actually follow-up for the task
MDEV-23902: MariaDB crash on calling function
to use correct query arena for a statement. In case invocation of
a function is in progress use its call arena, else use current
query arena that can be either a statement or a regular query arena.
We remove the call to update spider persistent table stats (sts/crd)
in spider_free_share(). This prevents spider from opening and closing
further tables during close(), which fixes the following issues:
MDEV-28739: ha_spider::close() is called during tdc_start_shutdown(),
which is called after query_cache_destroy(). Closing the sts/crd Aria
tables will trigger a call to Query_cache::invalidate_table(), which
will attempt to use the query cache mutex structure_guard_mutex
destroyed previously.
MDEV-29421: during ha_spider::close(), spider_free_share() could
trigger another spider_free_share() through updating sts/crd table,
because open_table() calls tc_add_table(), which could trigger another
ha_spider::close()...
Since spider sts/crd system tables are only updated here, there's no
use for these tables any more, and we remove all uses of these tables
too.
The removal should not cause any performance issue, as in memory
spider table stats are only updated based on a time
interval (spider_sts_interval and spider_crd_interval), which defaults
to 10 seconds. It should not affect accuracy either, due to the
infrequency of server restart. And inaccurate stats are not a problem
for optimizer anyway.
To be on the safe side, we defer the removal of the spider sts/crd
tables themselves to future.
btr_cur_update_in_place(): Update the DB_TRX_ID,DB_ROLL_PTR also on the
compressed copy of the page. In a test case, a server built with
cmake -DWITH_INNODB_EXTRA_DEBUG=ON would crash in page_zip_validate()
due to the inconsistency. In a normal debug build, a different assertion
would fail, depending on when the uncompressed page was restored from
the compressed page.
In MariaDB Server 10.5, this bug had already been fixed by
commit b3d02a1fcf (MDEV-12353).
sets of the first and second execution. The results of the first
and second execution are compared only if result logging is enabled
Comparing two result sets is done as comparing two strings.
Added a new method 'read_stmt_results' to get a result set
after execution of prepare statement.
- Allow database level access via `LOCK TABLES` to execute statement
`BACKUP [un]LOCK <object>`
- `BACKUP UNLOCK` works only with `RELOAD` privilege.
In case there is `LOCK TABLES` privilege without `RELOAD` privilege,
we check if backup lock is taken before.
If it is not we raise an error of missing `RELOAD` privilege.
- We had to remove any error/warnings from calling functions because
`thd->get_stmt_da()->m_status` will be set to error and will break
`my_ok()`.
- Added missing test coverage of `RELOAD` privilege to `main.grant.test`
Reviewer: <daniel@mariadb.org>
Statements affected by this bug have all the following
1) select statements with a sub-query
2) that sub-query includes a group-by clause
3) that group-by clause contains an expression
4) that expression has a reference to view
When a view is used in a group by expression, and that group by can be
eliminated in a sub-query simplification as part of and outer condition
that could be in, exists, > or <, then the table structure left behind
will have a unit that contains a null select_lex pointer.
If this happens as part of a prepared statement, or execute in a stored
procedure for the second time, then, when the statement is executed, the table
list entry for that, now eliminated, view is "opened" and "reinit"ialized.
This table entry's unit no longer has a select_lex pointer.
Prior to MDEV-31995 this was of little consequence, but now following this
null pointer will cause a crash.
Reviewed by Igor Babaev (igor@mariadb.com)
When the constant OS_AIO_N_PENDING_IOS_PER_THREAD is changed from 256 to 1
and the server is run with the minimum parameters
innodb_read_io_threads=1 and innodb_write_io_threads=2, two hangs
were observed.
tpool::cache<T>::put(T*): Ensure that get() in io_slots::acquire()
will be woken up when the cache previously was empty.
buf_pool_t::io_buf_t::reserve(): Schedule a possibly partial doublewrite
batch so that os_aio_wait_until_no_pending_writes() has a chance of
returning. Add a Boolean parameter and pass wait_for_reads=false inside
buf_page_decrypt_after_read(), because those calls will be executed
inside a read completion callback, and therefore
os_aio_wait_until_no_pending_reads() would block indefinitely.
- Add selected tables as shared keys for CTAS certification
- Set proper security context on the replayer thread
- Disallow CTAS command retry
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
This is caused by fact that VARIABLE_VALUE is defined in
variables_fields_info (sql_show.cc) as 2048.
wsrep_provider_options contain few path variables and
this could cause string truncation on deep and long
directory paths.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
trx_purge_free_segment(): If fseg_free_step_not_header() needs to be
called multiple times, acquire an exclusive latch on the
rollback segment header page after restarting the mini-transaction
so that the rest of this function cannot execute concurrently
with trx_undo_create() on the same rollback segment.
This fixes a regression that was introduced in
commit c14a39431b (MDEV-30753).
Note: The buffer-fixes that we are holding across the mini-transaction
restart will prevent the pages from being evicted from the buffer pool.
They may be accessed by other threads or written back to data files
while we are not holding exclusive latches.
Reviewed by: Vladislav Lesin
Problem:
========
- InnoDB fails to free the allocated buffer of stored cursor
when information schema query is interrupted.
Solution:
=========
- In case of error handling, information schema query should free
the allocated buffer to store the cursor.
- Commit e3bffd579f introduced the change
- Fixed with commit 2d85714448 in 10.4 (no removal of
`Wimplicit-fallthrough=2`)
- Fixed with commit 4a75b480e9 in 10.5+
- Closing PR #2817
Reviewed by: <monty@mariadb.org>
This will avoid issues like MDEV-32486
IDs used in
- spider_alloc_calc_mem_init()
- spider_string::init_calc_mem()
- spider_malloc()
- spider_bulk_alloc_mem()
- spider_bulk_malloc()
1. fix useless correction of dec_arg *after it was used*
2. use DECIMAL_NOT_SPECIFIED instead of NOT_FIXED_DEC, because the latter
is defined conditionally and has a wrong value in plugins
The server doesn't use the enforced storage engine in ALTER TABLE
without ENGINE clause to avoid an unwanted engine change.
However, the server tries to use the enforced engine in CREATE
INDEX. As a result, the false positive error is raised. The server
should not apply the enforced engine in CREATE INDEX too.
Wait for the disconnect of the other connection to complete, before running
SHOW BINLOG EVENTS. Otherwise the DROP TEMPORARY TABLE that is binlogged
during disconnect may not have appeared yet depending on thread scheduling.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Fix wrong change to rpl.rpl_shutdown_wait_slaves. After shutting down the
master, slaves may or may not succeed in reconnecting depending on the timing
on their reconnect relative to master restart. So don't assume all IO threads
will be running, just restart any slave that needs it.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Fix sporadic test failure in rpl.rpl_ssl1. The test incorrectly did a STOP
SLAVE too early, which could race with the expected 'Access denied' error.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Fix sporadic test failures in rpl.rpl_set_statement_default_master and
rpl.rpl_slave_load_tmpdir_not_exist. A race between START and STOP
SLAVE could leave an error condition that causes test failure after
MDEV-32168.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Test rpl.show_status_stop_slave_race-7126 now fails sporadically
because it is expected to sometimes (but not always) leave an error
condition after slave stop. Fix by explicitly allowing the error
condition in this case.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Fix a start/stop race that causes occasional test failure after more the more
strict error check of MDEV-32168.
Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
Calling SHOW BINLOG EVENTS FROM <offset> with an invalid offset
writes error messages into the server log about invalid reads. The
read errors that occur from this command should only be relayed back
to the user though, and not written into the server log. This is
because they are read-only and have no impact on server operation,
and the client only need be informed to correct the parameter.
This patch fixes this by omitting binary log read errors from the
server when the invocation happens from SHOW BINLOG EVENTS.
Additionally, redundant error messages are omitted when calling the
string based read_log_event from the IO_Cache based read_log_event,
as the later already will report the error of the former.
Reviewed By:
============
Kristian Nielsen <knielsen@knielsen-hq.org>
Andrei Elkin <andrei.elkin@mariadb.com>
To allow cmake -DWITH_ASAN=ON to work out of the box when using
newer compilers, we must increase the default thread stack size.
By design, AddressSanitizer will allocate some "sentinel" areas in
stack frames so that it can better catch buffer overflows, by trapping
access to memory addresses that reside between stack-allocated variables.
Apparently, some parameters related to this have been changed
recently, possibly to allow -fsanitize=address to catch more errors.
This fixes MDEV-30014, MDEV-29456, MDEV-29667, and MDEV-30049.
The server may ask storage engines to unlock when the original sql
command is not UNLOCK. This patch makes sure that spider honours these
requests, so that the server has the correct idea which tables are
locked and which are not.
MDEV-29456, MDEV-29667, MDEV-30049: a later LOCK statement would, as
the first step, unlock locked tables and clear the OPTION_TABLE_LOCK
bit in thd->variables.option_bits, as well as locked_tables_list,
indicating no tables are locked. If Spider does not unlock because the
sql command is not UNLOCK, and if after this the LOCK statement fails
to lock any tables, these indications that no tables are locked
remains, so a later UNLOCK TABLES; statement would not try to unlock
any table. Causing later statements requiring mdl locks to hang on
waiting until lock_wait_timeout (default 1h) has passed.
MDEV-30014: when a LOCK statement tries to lock more than one tables,
say t2 and t3 as in mdev_30014.test, and t2 succeeds but t3 fails, the
sql layer would try to undo by unlocking t2, and again, if Spider does
not honour this request, the sql layer would assume t2 has been
unlocked, but later actions on t2 or t2's remote table could hang on
waiting for the mdl.
Spider populates its lock lists (a hash) in store_lock(), and normally
clears them in the actual lock_tables(). However, if lock_tables()
fails, there's no reset_lock() method for storage engine handlers,
which can cause bad things to happen. For example, if one of the table
involved is dropped and recreated, or simply TRUNCATEd, when executing
LOCK TABLES again, the lock lists would be queried again in
store_lock(), which could cause access to freed space associated with
the dropped table.
