PRIVILEGE.
Backport from mysql-5.7 to mysql-5.5 and mysql-5.6.
BUG#13969578: TEMPORARY TABLE IN A DATABASE ON A READ-ONLY
INSTANCE CAN BE OVERWRITTEN
Analysis:
========
Creation or modification of a persistent table by a non-super user
is NOT ALLOWED in read_only mode. Only TEMPORARY tables are allowed
to be created or modified in read_only mode. But the creation of
a persistent table was being allowed when a temporary table of
the same name existed.
The routine which denies updating a non-temporary table in a
read_only mode does not handle the case of creation of a regular
table when a temporary table of the same exists.
Fix:
===
Handled the condition where an attempt is made to create a persistent
table having the same name as that of the temporary table. Hence
the creation of a persistent table by a non-super user when a
temporary table of the same exists is denied under read_only mode.
Also, implement MDEV-11027 a little differently from 5.5 and 10.0:
recv_apply_hashed_log_recs(): Change the return type back to void
(DB_SUCCESS was always returned).
Report progress also via systemd using sd_notifyf().
The reason for this is that stop slave takes LOCK_active_mi over the
whole operation while some slave operations will also need LOCK_active_mi
which causes deadlocks.
Fixed by introducing object counting for Master_info and not taking
LOCK_active_mi over stop slave or even stop_all_slaves()
Another benefit of this approach is that it allows:
- Multiple threads can run SHOW SLAVE STATUS at the same time
- START/STOP/RESET/SLAVE STATUS on a slave will not block other slaves
- Simpler interface for handling get_master_info()
- Added some missing unlock of 'log_lock' in error condtions
- Moved rpl_parallel_inactivate_pool(&global_rpl_thread_pool) to end
of stop_slave() to not have to use LOCK_active_mi inside
terminate_slave_threads()
- Changed argument for remove_master_info() to Master_info, as we always
have this available
- Fixed core dump when doing FLUSH TABLES WITH READ LOCK and parallel
replication. Problem was that waiting for pause_for_ftwrl was not done
when deleting rpt->current_owner after a force_abort.
Problem: CREATE TABLE using a fully qualified name with INDEX DIR/DATA DIR
option reports an error when the current database is not SET.
check_access() was incorrectly called with NULL as the database
argument in a situation where the database name was not needed for
the particular privilege being checked. This will cause the current
database to be used, or an error to be reported if there is no current
database.
Fix: Call check_access() with any_db as the database argument in this situation.
that must not send a response
Problem:- When using wsrep (w/ galera) and issuing commands that can
cause deadlocks, deadlock exception errors are sent in responses to
commands such as close prepared statement and close connection which,
by spec, must not send a response.
Solution:- In dispatch_command, we will handle COM_QUIT and COM_STMT_CLOSE
commands even in case of error.
Patch Credit:- Jaka Močnik
This commit is for optimizing WSREP(thd) macro.
#define WSREP(thd) \
(WSREP_ON && wsrep && (thd && thd->variables.wsrep_on))
In this we can safely remove wsrep and thd. We are not removing WSREP_ON
because this will change WSREP(thd) behaviour.
Patch Credit:- Nirbhay Choubay, Sergey Vojtovich
Problem:-
The condition that checks for node readiness is too strict as it does
not allow SELECTs even if these selects do not access any tables.
For example,if we run
SELECT 1;
OR
SELECT @@max_allowed_packet;
Solution:-
We need not to report this error when all_tables(lex->query_tables)
is NULL:
Tasks:-
Changes in wsrep_dirty_reads variable
1.) Global + Session scope (Current: session-only)
2.) Can be set using command line.
3.) Allow all commands that do not change data (besides SELECT)
4.) Allow prepared Statements that do not change data
5.) Works with wsrep_sync_wait enabled
Tasks:-
Changes in wsrep_dirty_reads variable
1.) Global + Session scope (Current: session-only)
2.) Can be set using command line.
3.) Allow all commands that do not change data (besides SELECT)
4.) Allow prepared Statements that do not change data
5.) Works with wsrep_sync_wait enabled
Tasks:-
Changes in wsrep_dirty_reads variable
1.) Global + Session scope (Current: session-only)
2.) Can be set using command line.
3.) Allow all commands that do not change data (besides SELECT)
4.) Allow prepared Statements that do not change data
5.) Works with wsrep_sync_wait enabled
Problem:-
The condition that checks for node readiness is too strict as it does
not allow SELECTs even if these selects do not access any tables.
For example,if we run
SELECT 1;
OR
SELECT @@max_allowed_packet;
Solution:-
We need not to report this error when all_tables(lex->query_tables)
is NULL:
Problem:-
The condition that checks for node readiness is too strict as it does
not allow SELECTs even if these selects do not access any tables.
For example,if we run
SELECT 1;
OR
SELECT @@max_allowed_packet;
Solution:-
We need not to report this error when all_tables(lex->query_tables)
is NULL:
Problem:-
The condition that checks for node readiness is too strict as it does
not allow SELECTs even if these selects do not access any tables.
For example,if we run
SELECT 1;
OR
SELECT @@max_allowed_packet;
Solution:-
We need not to report this error when all_tables(lex->query_tables)
is NULL:
700101
ANALYSIS:
=========
To set the time 'start_time' of query in THD, current time
is obtained by calling 'gettimeofday()'. On Solaris
platform, due to some system level issues, time obtained is
invalid i.e. its either greater than 2038 (max signed value
to hold microseconds since 1970) or 1970 (0 microseconds
since 1970). In these cases, validation checks infer that
the 'start_time' is invalid and mysql server initiates the
shutdown process. But the reason for shutdown is not logged.
FIX:
====
We are now logging appropriate message when shutdown is
triggered in the above mentioned scenarios. Now, even if
the initial validation checks infer that the 'start_time'
is invalid, server shutdown is not initiated immediately.
Before initiating the server shutdown, the process of
setting 'start_time' and validating it is reiterated (for
max 5 times). If correct time is obtained in these 5
iterations then server continues to run.
