Don't compare "field == table->next_number_field" because the field
can be special nullable field copy created by the trigger.
Compare field_index values instead.
Cannot do password validation in fix_lex_user(), we don't know
there what "GRANT ... TO user" means - creating a new user with
an empty password (need validation) or granting privileges
to an existing user (no validation needed).
Move validation down into replace_user_table(). And copy into
check_change_password().
Was:
* LEX_USER::password was storing sometimes
plaintext password and sometimes password hash
* LEX_USER::auth was storing sometimes password hash and
sometimes plugin authentication string
Now:
* LEX_USER::pwtext stores the password in plain-text
* LEX_USER::pwhash stores the password hash
* LEX_USER::auth stores the plugin authentication string
allow more characters in a valid user/group name:
* POSIX allows dashes '-' and dots '.'
* also the name may end with a dollar sign '$'
for our purposes it's enough to allow [-.$] anywhere in the name
different fix. remove old ones, wait for THD to be fully
initialized before continuing with the server startup process.
This reverts commits db2e21b, 13615c5, 3f515a0, 70113ee.
Undo the change in test_if_skip_sort_order() that set ref_key=-1 when
a variant of index_merge is used (was made in fix for MDEV-9021).
It turned out that test_if_cheaper_ordering() call below assumes that
ref_key=-1 means "no index is used", that is, "an inefficient full table
scan is done".
This is not the same as index_merge, index_merge can actually be quite
efficient. So, ref_key=MAX_KEY denotes the fact that some index is used,
not any given index.
In order to get all the input from addr2line we must read in a loop,
until the response is complete. Also, in case that the response is
malformed, we must not end up reading invalid memory.
Due to a hack that has propagated to the maria storage engine, undefined
behaviour would result by bypassing the initialization code of variables
after my_thread_init().
By refactoring the nested logic into a separate function, this problem
is resolved.
This occurs when replication stops with an error, domain-based parallel
replication is used, and the GTID position contains more than one domain.
Furthermore, it relates to the case where the SQL thread is restarted
without first stopping the IO thread.
In this case, the file/offset relay-log position does not correctly
represent the slave's multi-dimensional position, because other domains may
be far ahead of, or behind, the domain with the failing event. So the code
reverts the relay log position back to the start of a relay log file that is
known to be before all active domains.
There was a bug that when the SQL thread was restarted, the
rli->relay_log_state was incorrectly initialised from @@gtid_slave_pos. This
position will likely be too far ahead, due to reverting the relay log
position. Thus, if the replication fails again after the SQL thread restart,
the rli->restart_gtid_pos might be updated incorrectly. This in turn would
cause a second SQL thread restart to replicate from the wrong position, if
the IO thread was still left running.
The fix is to initialise rli->relay_log_state from @@gtid_slave_pos only
when we actually purge and re-fetch relay logs from the master, not at every
SQL thread start.
A related problem is the use of sql_slave_skip_counter to resolve
replication failures in this kind of scenario. Since the slave position is
multi-dimensional, sql_slave_skip_counter can not work properly - it is
indeterminate exactly which event is to be skipped, and is unlikely to work
as expected for the user. So make this an error in the case where
domain-based parallel replication is used with multiple domains, suggesting
instead the user to set @@gtid_slave_pos to reliably skip the desired event.
MariaDB 5.5 built in debug gets unhappy with mutexes.
Although everything is correct, some DBUG_ASSERT can happen.
So this patch keeps safe_mutex silent.
Fix test whether process is alive in mysqltest.
Also fix SHUT_RD definition on Windows to be SD_RECEIVE.
SD_BOTH was used instead prior to this patch, and this would
occasionally make mysql_shutdown() fail - when the socket for the current connection
is not able send the COM_SHUTDOWN response anymore.
If GCC or CLang compile with link time optimization (-flto),
they throw an error during link , when lto sees a
function (e.g mysql_real_connect) is redeclared as "external void *"
in libmysql_exports.cc
The fix disables -flto for generated libmysql_exports.cc
The problem was that wait_for_slave_io_to_start reported that the io thread
was ready, when it was still initializing. This caused test suite to
continue too early, for example before the semi sync plugin was properly
enabled.
Fixed by introducing a new internal stage: "Preparing". Slave_IO_Running is
now set to "Yes" only when all initializing is done and the IO thread is
ready to read things from the master.
The only test affected by this change is rpl_flsh_tbls, which got stuck in
the preparing phase while trying to read the GTID position from a table.
Fixed by having this test waiting for Preparing instead of Yes.
- Added testing if connection is killed to shortcut reading of connection data
This will allow us later in 10.2 to do a cleaner shutdown of slaves (less errors in the log)
- Add new status variables: Slaves_connected, Slaves_running and Slave_connections.
- Use MYSQL_SLAVE_NOT_RUN instead of 0 with slave_running.
- Don't print obvious extra warnings to the error log when slave is shut down normally.
