database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-08-08 11:22:35 +03:00
Code Activity

Fixed warning about unitialized mutex when mysqld couldn't start.

Browse Source 
sql/handler.cc:
  Cleaned up comments
This commit is contained in:
unknown
2004-06-23 16:39:56 +03:00
parent 540121e1f9
commit a3244c68f0
2 changed files with 24 additions and 19 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
sql/handler.cc
View File

@@ -578,10 +578,11 @@ int ha_rollback_trans(THD *thd, THD_TRANS *trans)
if ((trans == &thd->transaction.all) && mysql_bin_log.is_open())
{
/*
Update the binary log with a BEGIN/ROLLBACK block if we have cached some
queries and we updated some non-transactional table. Such cases should
be rare (updating a non-transactional table inside a transaction...).
Count disk writes to trans_log in any case.
Update the binary log with a BEGIN/ROLLBACK block if we have
cached some queries and we updated some non-transactional
table. Such cases should be rare (updating a
non-transactional table inside a transaction...). Count disk
writes to trans_log in any case.
*/
if (my_b_tell(&thd->transaction.trans_log))
{
@@ -626,12 +627,12 @@ int ha_rollback_trans(THD *thd, THD_TRANS *trans)
simply truncate the binlog cache, we lose the part of the binlog cache where
the update is. If we want to not lose it, we need to write the SAVEPOINT
command and the ROLLBACK TO SAVEPOINT command to the binlog cache. The latter
is easy: it's just write at the end of the binlog cache, but the former should
be *inserted* to the place where the user called SAVEPOINT. The solution is
that when the user calls SAVEPOINT, we write it to the binlog cache (so no
need to later insert it). As transactions are never intermixed in the binary log
(i.e. they are serialized), we won't have conflicts with savepoint names when
using mysqlbinlog or in the slave SQL thread.
is easy: it's just write at the end of the binlog cache, but the former
should be *inserted* to the place where the user called SAVEPOINT. The
solution is that when the user calls SAVEPOINT, we write it to the binlog
cache (so no need to later insert it). As transactions are never intermixed
in the binary log (i.e. they are serialized), we won't have conflicts with
savepoint names when using mysqlbinlog or in the slave SQL thread.
Then when ROLLBACK TO SAVEPOINT is called, if we updated some
non-transactional table, we don't truncate the binlog cache but instead write
ROLLBACK TO SAVEPOINT to it; otherwise we truncate the binlog cache (which