fail CREATE SERVER foreign data wrapper is "mysql"
and neither HOST nor SOCKET are specified.
Also default PORT to 3306 (again, only for foreign
data wrapper "mysql")
* pass LEX_STRING's from the parser, don't ignore the length only to strlen later
* init LEX::server_options only for SERVER commands, not for every statement
* don't put temporary values into a global persistent memroot
but really it's just scratching a surface
If we didn't do it, SJ-Materialization table would appear to
EXPLAIN JSON code as having different keyparts than it actually
has. This caused unpredictable content in "used_key_parts"
- Switch Explain data structure from "flat" representation of
SJ-Materialization into nested one.
- Update functions that print tabular output to operate on the
nested structure.
- Add function to generate JSON output.
- Basic support for JOIN buffering
- The output is not polished but catches the main point:
tab->select_cond and tab->cache_select->cond are printed separately.
- Hash join support is poor still.
- Also fixed identation in JOIN_TAB::save_explain_data
Writing JSON:
- Fix a bug in Single_line_formatting_helper
- Add Json_writer_nesting_guard - safety class
EXPLAIN JSON support
- Add basic subquery support
- Add tests for UNION/UNION ALL.
The replication relay log position was sometimes updated incorrectly at the
end of a transaction in parallel replication. This happened because the relay
log file name was taken from the current Relay_log_info (SQL driver thread),
not the correct value for the transaction in question.
The result was that if a transaction was applied while the SQL driver thread
was at least one relay log file ahead, _and_ the SQL thread was subsequently
stopped before applying any events from the most recent relay log file, then
the relay log position would be incorrect - wrong relay log file name. Thus,
when the slave was started again, usually a relay log read error would result,
or in rare cases, if the position happened to be readable, the slave might
even skip arbitrary amounts of events.
In GTID mode, the relay log position is reset when both slave threads are
restarted, so this bug would only be seen in non-GTID mode, or in GTID mode
when only the SQL thread, not the IO thread, was stopped.
Simply disallowing equality propagation into LIKE.
A more delicate fix is be possible, but it would need too many changes,
which is not desirable in 10.0 at this point.
Moving Item_bool_func2 and Item_func_opt_neg from Item_int_func to
Item_bool_func. Now all functions that return is_bool_func()=true
have a common root class Item_bool_func.
This change is needed to fix MDEV-7149 properly.
The bug was in DEBUG_SYNC. When waiting, debug_sync_execute() temporarily sets
thd->mysys_var->current_mutex to a new value while waiting. However, if the
old value of current_mutex was NULL, it was not restored, current_mutex
remained set to the temporary value (debug_sync_global.ds_mutex).
This made possible the following race: Thread T1 goes to KILL thread T2. In
THD::awake(), T1 loads T2->mysys_var->current_mutex, it is set to ds_mutex, T1
locks this mutex.
Now T2 runs, it does ENTER_COND, it sets T2->mysys_var->current_mutex to
LOCK_wait_commit (for example).
Then T1 resumes, it reloads mysys_var->current_mutex, now it is set to
LOCK_wait_commit, T1 unlocks this mutex instead of the ds_mutex that it locked
previously.
This causes safe_mutex to assert with the message: "Trying to unlock mutex
LOCK_wait_commit that wasn't locked".
The fix is to ensure that DEBUG_SYNC also will restore
mysys_var->current_mutex in the case where the original value was NULL.
When a master slave restarts, it logs a special restart format description
event in its binlog. When the slave sees this event, it knows it needs to roll
back any active partial transaction, in case the master crashed previously in
the middle of writing such transaction to its binlog.
However, there was a bug where this rollback did not reset rgi->pending_gtid.
This caused the @@gtid_slave_pos to be updated incorrectly with the GTID of
the partial transaction that was rolled back.
Fix this by always clearing rgi->pending_gtid in cleanup_context(), hopefully
preventing similar bugs from turning up in other special cases where a
transaction is rolled back during replication.
Thanks to Pavel Ivanov for tracking down the issue and providing a test case.
- Drop all tables in explain_json.test
- Tabular form should print ref='' when type='fulltext' (another peculiarity
of the traditional EXPLAIN format)
- String_list::append_str should allocate memory for \0, too
- Some temporary code for EXPLAIN JSON and join buffering.
* adjust viossl.c to take account the new code
(SSL_get_error is used now, cannot simply remap it)
* remove unnecessary version check
* update the test to 10.0
When the optimizer considers an option to use Loose Scan, it should
still consider UNIQUE keys (Previously, MDEV-4120 disabled loose scan
for all kinds of unique indexes. That was wrong)
However, we should not use Loose Scan when trying to satisfy
"SELECT DISTINCT col1, col2, .. colN"
when using an index defined as UNIQU(col1, col2, ... colN).
