| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ |
|
| | | |
|
| | |\ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
SP with UPDATE
1. Always drop merged_for_insert flag on cleanup (there could be errors which prevent TABLE to be assigned)
2. Make more precise cleanup of select parts which was touched
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
st_select_lex::handle_derived()
st_select_lex::handle_derived() and mysql_handle_list_of_derived() had
exactly the same implementations.
- Adding a new method LEX::handle_list_of_derived() instead
- Removing public function mysql_handle_list_of_derived()
- Reusing LEX::handle_list_of_derived() in st_select_lex::handle_derived()
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
candle.exe's preprocessor flags (-dHaveUpgradeWizard=0 -DHaveInnodb=1)
were not passed correctly to EXECUTE_PROCESS
Fix is to make a list out of the EXTRA_WIX_PREPROCESSOR_FLAGS string,
and use the preprocessor flags list in EXECUTE_PROCESS.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
For multi-table views with LOAD, updates are not allowed, so
we should just throw an error.
|
| | | |
| | |
| | |
| | |
| | | |
For singe-table views, we need to find the bottom most base table in the embedded views
and then update that table
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
innodb_default_encryption_key_id!=1
The problem with the InnoDB table attribute encryption_key_id is that it is
not being persisted anywhere in InnoDB except if the table attribute
encryption is specified and is something else than encryption=default.
MDEV-17320 made it a hard error if encryption_key_id is specified to be
anything else than 1 in that case.
Ideally, we would always persist encryption_key_id in InnoDB. But, then we
would have to be prepared for the case that when encryption is being enabled
for a table whose encryption_key_id attribute refers to a non-existing key.
In MariaDB Server 10.1, our best option remains to not store anything
inside InnoDB. But, instead of returning the error that MDEV-17320
introduced, we should merely issue a warning that the specified
encryption_key_id is going to be ignored if encryption=default.
To improve the situation a little more, we will issue a warning if
SET [GLOBAL|SESSION] innodb_default_encryption_key_id is being set
to something that does not refer to an available encryption key.
Starting with MariaDB Server 10.2, thanks to MDEV-5800, we could open the
table definition from InnoDB side when the encryption is being enabled,
and actually fix the root cause of what was reported in MDEV-17320.
|
| | | |
| | |
| | |
| | |
| | | |
Replaced debug to debug_dbug on 10.1 on galera suite. Nothing to do
in wsrep and galera_3nodes suites.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Galera cluster size change
This will allow test binlog.binlog_stm_binlog to pass more often.
Note that this is not a real fix to that test failure.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If we have a 2+ node cluster which is replicating from an async master
and the binlog_format is set to STATEMENT and multi-row inserts are executed
on a table with an auto_increment column such that values are automatically
generated by MySQL, then the server node generates wrong auto_increment
values, which are different from what was generated on the async master.
In the title of the MDEV-9519 it was proposed to ban start slave on a Galera
if master binlog_format = statement and wsrep_auto_increment_control = 1,
but the problem can be solved without such a restriction.
The causes and fixes:
1. We need to improve processing of changing the auto-increment values
after changing the cluster size.
2. If wsrep auto_increment_control switched on during operation of
the node, then we should immediately update the auto_increment_increment
and auto_increment_offset global variables, without waiting of the next
invocation of the wsrep_view_handler_cb() callback. In the current version
these variables retain its initial values if wsrep_auto_increment_control
is switched on during operation of the node, which leads to inconsistent
results on the different nodes in some scenarios.
3. If wsrep auto_increment_control switched off during operation of the node,
then we must return the original values of the auto_increment_increment and
auto_increment_offset global variables, as the user has set. To make this
possible, we need to add a "shadow copies" of these variables (which stores
the latest values set by the user).
https://jira.mariadb.org/browse/MDEV-9519
|
| | | |
| | |
| | |
| | |
| | |
| | | |
ib_wqueue_is_empty(): protect ib_list_is_empty() call
Closes #1202
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
wsrep.cnf.sh
Since MariaDB 10.1.17 the new default values for wsrep_max_ws_rows and wsrep_max_ws_size were set:
wsrep_max_ws_rows
Default Value:
0 (>= MariaDB Galera 10.0.27, MariaDB 10.1.17)
131072 (<= MariaDB Galera 10.0.26, MariaDB 10.1.16)
wsrep_max_ws_size
Default Value:
2147483647 (2GB, >= MariaDB Galera 10.0.27, MariaDB 10.1.17)
1073741824 (1GB, <= MariaDB Galera 10.0.26, MariaDB 10.1.16)
|
| | | |
| | |
| | |
| | | |
with acl_cache->lock mutex
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
mariabackup"
This reverts commit 3262967008bf2c2978bbf97960a3ea168fec9c26.
It was checked in by mistake
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
failed CREATE OR REPLACE
Failed CREATE OR REPLACE for existing user removes that user
from acl_users array. Thus dependend structures (roles, check_host) must
be rebuilt.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
but even if this script called as /bin/mysql_install_db
it is still standard install and scripts are in /usr/share/
(but not in the /share/)
2. fix of bindir path
|
| | | | | |
|
| |\ \ \ \
| |/ / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
By pure chance the macro worked in the cases it was used, but
better to get this fixed!
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
dict_create_foreign_constraints_low(): Clean up the way in
which the error messages are initialized, and ensure that
the table name is always initialized.
|
| |/ / / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Most of the mtr tests in the galera_3nodes suite fail
for a variety of reasons with a variety of errors.
This patch fixes several substantial flaws
in the galera_3nodes suite tests and in the mtr framework
service files, adapting the tests from galera_3nodes
for the current version of MariaDB.
This patch also synchronizes some galera_3nodes-related
files with the latest changes made for MDEV-17835 (v2 patch)
and for MDEV-18379 in other branches (10.2 and 10.3).
Closes #1161
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The code path where the table was not being rebuilt during ALTER TABLE
was not covered by the test. Add coverage, and remove the debug assertion
that could fail in this case.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
i_s_innodb_mutexes_fill_table(): Use the C++ RAII pattern
to ensure that the mutexes are released if an OK()
macro returns from the function prematurely.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
buf_page_is_corrupted(): Read the global variable srv_checksum_algorithm
only once in order to avoid a race condition when
SET GLOBAL innodb_checksum_algorithm=...;
is being executed concurrently with this function.
|
| |\ \ \
| |/ /
| | |
| | | |
This is joint work with Oleksandr Byelkin.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
ha_innobase::commit_inplace_alter_table(): Do not crash if
innobase_update_foreign_cache() returns an error. It can return
an error on ALTER TABLE if an inconsistent FOREIGN KEY constraint
was created earlier when SET foreign_key_checks=0 was in effect.
Instead, report a warning to the client that constraints cannot
be loaded.
|
| | | |
| | |
| | |
| | |
| | | |
ha_innobase::prepare_inplace_alter_table(): Filter out duplicates
from ha_alter_info->alter_info->drop_list.elements.
|
| | | |
| | |
| | |
| | |
| | | |
innobase_rename_column_try(): Declare fk_evict as std::set
instead of std::list, in order to filter out duplicates.
|
| | | | |
|
| | | | |
|
| | |\ \
| | |/ |
|
| | | |
| | |
| | |
| | |
| | | |
@@open_files_limit now behaves differenly and cannot
be used to skip the test anymore.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Disable LOAD DATA LOCAL INFILE suport by default and
auto-enable it for the duration of one query, if the query
string starts with the word "load". In all other cases the application
should enable LOAD DATA LOCAL INFILE support explicitly.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the rlimit.rlim_cur value returned by getrlimit is not the
RLIM_INFINITY magic constant, but a *very* large number, we can allocate
too many open files. Restrict set_max_open_files to only return at most
max_file_limit, as passed via its parameter.
|
| | | | |
|
| | |\ \ |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
fixed by MDEV-17531 by Marko
|
| | |\ \ \ |
|
