When a GTID event is executed, we remember the contained GTID position so that
when we have applied the entire event group we can commit it to
gtid_slave_pos.
However, if the event group fails to apply due to some error and the SQL
thread aborts, the code did not correctly clear the remembered GTID. Thus,
when SQL thread was restarted, the old GTID of the failing event group was
incorrectly updated to gtid_slave_pos when the initial rotate event was
executed, corrupting the GTID position.
After single row substitutions there might appear new equalities.
They should be properly propagated to all AND/OR levels the WHERE
condition. It's done now with an additional call of remove_eq_conds().
The main bug here was the following situation:
Suppose we set up a completely new master2 as an extra multi-master to an
existing slave that already has a different master1 for domain_id=0. When the
slave tries to connect to master2, master2 will not have anything that slave
requests in domain_id=0, but that is fine as master2 is supposedly meant to
serve eg. domain_id=1. (This is MDEV-4485).
But suppose that master2 then actually starts sending events from
domain_id=0. In this case, the fix for MDEV-4485 was incomplete, and the code
would fail to give the error that the position requested by the slave in
domain_id=0 was missing from the binlogs of master2. This could lead to lost
events or completely wrong replication.
The patch for this bug fixes this issue.
In addition, it cleans up the code a bit, getting rid of the fake_gtid_hash in
the code. And the error message when slave and master have diverged due to
alternate future is clarified, as requested in the bug description.
This patch almost totally revised the patch for bug mdev-4177.
The latter had too many defects. In particular, it did not
propagate multiple equalities formed when merging a degenerate
disjunct into underlying AND formula.
failed in TABLE_SHARE* tdc_acquire_share(THD*, const char*,
const char*, const char*, uint, uint, TABLE**)
Removed false assertions.
When multiple threads acquire the same previously unused share,
only one thread shall remove share from unused list (the one that
has was_unused == true). Other threads will ignore this step and
may continue even if share is not yet removed from unused list.
Added partition_exchange test.
Do not set HA_OPTION_PACK_RECORD for InnoDB specific row formats
(e.g. COMPACT, REDUNDANT). Adjusted mysql_compare_tables() accordingly.
information function. This solve the problem of uninitialised zone
that was detected by valgrind.
modified:
storage/connect/myconn.cpp
storage/connect/odbconn.cpp
storage/connect/tabfmt.cpp
storage/connect/tabutil.cpp
storage/connect/tabwmi.cpp
Following variables do not require LOCK_open protection anymore:
- table_def_cache (renamed to tdc_hash) is protected by rw-lock
LOCK_tdc_hash;
- table_def_shutdown_in_progress doesn't need LOCK_open protection;
- last_table_id use atomics;
- TABLE_SHARE::ref_count (renamed to TABLE_SHARE::tdc.ref_count)
is protected by TABLE_SHARE::tdc.LOCK_table_share;
- TABLE_SHARE::next, ::prev (renamed to tdc.next and tdc.prev),
oldest_unused_share, end_of_unused_share are protected by
LOCK_unused_shares;
- TABLE_SHARE::m_flush_tickets (renamed to tdc.m_flush_tickets)
is protected by TABLE_SHARE::tdc.LOCK_table_share;
- refresh_version (renamed to tdc_version) use atomics.
This a an old legacy performance bug.
When a very selective range scan existed for the second table in a join,
and, at the same time, there was another range condition depending on the
fields of the first table, the optimizer chose a plan with
'Range checked for each record'. This plan was extremely inefficient in
comparison with the regular selective range scan.
As a matter of fact the range scan chosen for each record was the same as
that selective range scan.
Changed the test case for bug 24776 to preserve the old output for explain.
when deleting one key of a INI table with layout=Row. The same happens
for layout=column but this is normal as one line is one section.
modified:
storage/connect/tabsys.cpp
- Should fix a valgrind warning in CHRBLK::GetValPtrEx
modified:
storage/connect/valblk.cpp
* use sql_mode_for_dates() where appropriate.
* always specify an argument for sql_mode_for_dates()
(future-proof. easier to notice and fix if the caller
will start using thd from a local variable or an argument)
modified:
storage/connect/ha_connect.cc
storage/connect/ha_connect.h
storage/connect/plgdbsem.h
- Fiw a bug making records_in_range sometimes return a negative
value.
modified:
storage/connect/xindex.cpp
remove unused HA_CAN_EXPORT
(with the merge of "FLUSH TABLE <table_list> FOR EXPORT",
this functionality should be added back, but differently -
no table flag, handler::extra() returns an error instead)
