17eeb34...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
MDEV-33173 : Galera test case galera_sr_kill_slave_before_apply unstable
Add wait_condition to make sure tables are created before next
operations.
Signed-off-by: Julius Goryavsky <email address hidden>
6cdb993...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
MDEV-33172 : Galera test case galera_mdl_race unstable
Add wait_condition between debug sync SIGNAL points and other
expected state conditions and refactor actual sync point for
easier to use in test case.
Signed-off-by: Julius Goryavsky <email address hidden>
5367b99...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
MDEV-33036 : Galera test case galera_3nodes.galera_ist_gcache_rollover has warning
Correct used configuration and force server restarts before test
case. Add wait condition instead of sleep to verify that
all expected nodes are back to cluster.
Signed-off-by: Julius Goryavsky <email address hidden>
9341b0d...
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>
ed4f165...
by
=?utf-8?q?Jan_Lindstr=C3=B6m?= <email address hidden>
MDEV-32837 long unique does not work like unique key when using replace
write_record() when performing REPLACE has an optimization:
- if the unique violation happened in the last unique key, then do UPDATE
- otherwise, do DELETE+INSERT
This patch changes the way of detecting if this optimization
can be applied if the table has long (hash based) unique
(i.e. UNIQUE..USING HASH) constraints.
Problem:
The old condition did not take into account that
TABLE_SHARE and TABLE see long uniques differently:
- TABLE_SHARE sees as HA_KEY_ALG_LONG_HASH and HA_NOSAME
- TABLE sees as usual non-unique indexes
So the old condition could erroneously decide that the UPDATE optimization
is possible when there are still some unique hash constraints in the table.
Fix:
- If the current key is a long unique, it now works as follows:
UPDATE can be done if the current long unique is the last
long unique, and there are no in-engine (normal) uniques.
- For in-engine uniques nothing changes, it still works as before:
If the current key is an in-engine (normal) unique:
UPDATE can be done if it is the last normal unique.
