a3707a7...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
MDEV-33138 : Galera test case MW-336 unstable
Add more inserts before wsrep_slave_threads is set to 1 and
add wait_condition to wait all of them are replicated before
wait_condition about number of wsrep_slave_threads.
Signed-off-by: Julius Goryavsky <email address hidden>
7cbaaf1...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
MDEV-30456 ALTER TABLE algorithm clause not replicated
Fixing the regression happening with galera.galera_toi_ddl_nonconflicting
The problem, surfaced by the test, was due to multi-statement used in the test.
The test issues two queries, as multi-statement:
--send ALTER TABLE t1 ADD COLUMN f3 INTEGER; INSERT INTO t1 (f1, f2) VALUES (DEFAULT, 123);
With this, the session's THD structure has in query_string member
the full multi-statement, and this was used as base query in
TOI replication rewriting.
The fix is to pass actual length of the ALTER statement part for
TOI replication.
Signed-off-by: Julius Goryavsky <email address hidden>
3dd5662...
by
Julius Goryavsky <email address hidden>
MDEV-30456 ALTER TABLE algorithm clause not replicated
If user has specified the desired alter algorithm by using session
variable alter_algorithm, and not specifying the algorithm in the
ALTER SQL statement, then the ALTER will be processed in sending node
according the algorithm chosen by the alter_algorithm variable.
But in receiving nodes, appliers cannot see this session variable,
and will use the default algorithm when executing the ALTER.
The fix in this commit, will check if user has set alter_algorithm
variable and has not specified the algorithm clause in the ALTER
statement, and in such case will rewrite the original ALTER statement
appended by the algorithm clause. This rewritten ALTER statement will
be used in replication.
The commit has also new mtr test: galera.galera_alter_table_algorithm
which verifies that ALTER query rewrite happens when needed
Signed-off-by: Julius Goryavsky <email address hidden>
MDEV-33191 spider: fix dbton_id when iterating over links
There are two array fields in spider_share with similar names:
share->use_sql_dbton_ids that maps from i to the i-th dbton used by
share. Thus it should be used only when i iterates over all distinct
dbtons used by share.
share->sql_dbton_ids that maps from i to the dbton used by the i-th
link of the share. Thus it should be used only when i iterates over
all links of a share.
We correct instances where share->sql_dbton_ids should be used instead
of share->use_sql_dbton_ids.
