sending SIGHUP.
There were two problems:
- after some recent fix, the server started to crash after
receiving SIGHUP. That happened because LEX of new THD-object
was not properly initialized.
- user-specified log options were ignored when logs were reopened.
The fix is to 1) initialize LEX and 2) take user-specified options
into account.
There is no test case in this CS, because our test suite does not
support sending SIGHUP to the server.
a SELECT doesn't cause ROLLBACK of statem".
The idea of the fix is to ensure that we always commit the current
statement at the end of dispatch_command(). In order to not issue
redundant disc syncs, an optimization of the two-phase commit
protocol is implemented to bypass the two phase commit if
the transaction is read-only.
- Replace per-thread signal()'s with SetUnhandledExceptionFilter().
The only remaining signal() is for SIGABRT (default abort()
handler in VS2005 is broken, i.e removes user exception filter)
- remove MessageBox()'es from error handling code
- Windows port for print_stacktrace() and write_core()
- Cleanup, removed some unused functions
pre-locking.
The crash was caused by an implicit assumption in check_table_access() that
table_list parameter is always a part of lex->query_tables.
When iterating over the passed list of tables, check_table_access() used
to stop only when lex->query_tables_last_not_own was reached.
In case of pre-locking, lex->query_tables_last_own is not NULL and points
to some element of lex->query_tables. When the parameter
of check_table_access() was not part of lex->query_tables, loop invariant
could never be violated and a crash would happen when the current table
pointer would point beyond the end of the provided list.
The fix is to change the signature of check_table_access() to also accept
a numeric limit of loop iterations, similarly to check_grant(), and
supply this limit in all places when we want to check access of tables
that are outside lex->query_tables, or just want to check access to one table.
Here is the scenario that causes the failure.(by Mats)
1. The to-be corrupt log event (let's call it X), is split into two
packets B and C on the network level (net_write_buff()). The parts
are X = (x',x''). The part x' ends up in packet B and part x''
ends up in packet C. Prior to the corrupt event X, the event Y has
been written successfully, but has been split into two packets as
well, which we call (y',y'').
2. The master sends packet A = (y'',x') to the slave, increases the
packet sequence number, the slave receives the packet, but fails
to reply before the master gets a timeout.
3. Since the master got a timeout, it reports failure, and aborts
sending the binary log by exiting mysql_binlog_send(). However, it
leaves the buffer intact, still holding y'' (but not x', since the
write_pos is not increased).
4. After exiting mysql_binlog_send(), the master does a
disconnection of the client thread, which involves sending an
error message e to the client (i.e., the slave).
5. In this case, net_write_buff() is used again, but this time the
old contents of the packet is used so that the new packet is
D = (y'',e). Note that this will use a new packet sequence number,
since the packet number was increased in step 2.
6. The slave receives the tail y'' of the Y log event, concatenates
this with x' (which it already received), and writes the event
(x',y'') it to the relay log since it hasn't noticed anything is
amiss.
7. It then tries to read more bytes, which is either e (if the length
given for X just happened to match the length given for Y, or just
plain garbage because the slave is out of sync with what is
actually sent.
8. After a while, the SQL thread tries to execute the event (x',y''),
which is very likely to be just nonsense.
The problem can be fixed by not resetting net->error after the call of
mysql_binlog_send, so the error message will not be sent and the connection
will be closed.
The problem is that some DDL statements (ALTER TABLE, CREATE
TRIGGER, FLUSH TABLES, ...) when under LOCK TABLES need to
momentarily drop the lock, reopen the table and grab the write
lock again (using reopen_tables). When grabbing the lock again,
reopen_tables doesn't pass a flag to mysql_lock_tables in
order to ignore the impending global read lock, which causes a
assertion because LOCK_open is being hold. Also dropping the
lock must not signal to any threads that the table has been
relinquished (related to the locking/flushing protocol).
The solution is to correct the way the table is reopenned
and the locks grabbed. When reopening the table and under
LOCK TABLES, the table version should be set to 0 so other
threads have to wait for the table. When grabbing the lock,
any other flush should be ignored because it's theoretically
a atomic operation. The chosen solution also fixes a potential
discrepancy between binlog and GRL (global read lock) because
table placeholders were being ignored, now a FLUSH TABLES WITH
READ LOCK will properly for table with open placeholders.
It's also important to mention that this patch doesn't fix
a potential deadlock if one uses two GRLs under LOCK TABLES
concurrently.
cause ROLLBACK of statement", part 1. Review fixes.
Do not send OK/EOF packets to the client until we reached the end of
the current statement.
This is a consolidation, to keep the functionality that is shared by all
SQL statements in one place in the server.
Currently this functionality includes:
- close_thread_tables()
- log_slow_statement().
After this patch and the subsequent patch for Bug#12713, it shall also include:
- ha_autocommit_or_rollback()
- net_end_statement()
- query_cache_end_of_result().
In future it may also include:
- mysql_reset_thd_for_next_command().
When read_only option was enabled, a user without SUPER privilege could
perform CREATE DATABASE and DROP DATABASE operations.
This patch adds a check to make sure this isn't possible. It also attempts to
simplify the logic used to determine if relevant tables are updated,
making it more human readable.
clause is silently ignored
When symbolic links are disabled by command line option or
NO_DIR_IN_CREATE sql mode, CREATE TABLE silently ignores
DATA/INDEX DIRECTORY options.
With this fix a warning is issued when symbolic links are disabled.
The problem was that THD::killed was reset after a command was
read from the socket, but before it was actually handled. That lead
to a race: if another KILL statement was issued for this connection
in the middle of reading from the socket and processing a command,
THD::killed state would be cleaned.
The fix is to move this cleanup into net_send_error() function.
A sample test case exists in binlog_killed.test:
- connection 1: start a new transaction on table t1;
- connection 2: send query to the server (w/o waiting for the
result) to update data in table t1 -- this query will be blocked
since there is unfinished transaction;
- connection 1: kill query in connection 2 and finish the transaction;
- connection 2: get result of the previous query -- it should be
the "query-killed" error.
This test however contains race condition, which can not be fixed
with the current protocol: there is no way to guarantee, that the
server will receive and start processing the query in connection 2
(which is intended to get blocked) before the KILL command (sent in
the connection 1) will arrive. In other words, there is no way to
ensure that the following sequence will not happen:
- connection 1: start a new transaction on table t1;
- connection 1: kill query in connection 2 and finish the transaction;
- connection 2: send query to the server (w/o waiting for the
result) to update data in table t1 -- this query will be blocked
since there is unfinished transaction;
- connection 2: get result of the previous query -- the query will
succeed.
So, there is no test case for this bug, since it's impossible
to write a reliable test case under the current circumstances.
Loading 4.1 into 5.0 or 5.1 failed silently because procs_priv table missing.
This caused the server to crash on any attempt to store new grants because
of uninitialized structures.
This patch breaks up the grant loading function into two phases to allow
for procs_priv table to fail with an warning instead of crashing the server.
