Commit cd049201 authored by monty@mysql.com's avatar monty@mysql.com

Merge bk-internal.mysql.com:/home/bk/mysql-4.1

into mysql.com:/home/my/mysql-4.1
parents b42fc1e7 d0507ca7
......@@ -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
......
......@@ -24,13 +24,11 @@
#pragma implementation // gcc: Class implementation
#endif
#include "mysql_priv.h"
#include "tzfile.h"
#include <m_string.h>
#include <my_dir.h>
/*
Now we don't use abbreviations in server but we will do this in future.
*/
......@@ -53,8 +51,8 @@ typedef struct ttinfo
uint tt_abbrind; // Index of start of abbreviation for this time type.
#endif
/*
We don't use tt_ttisstd and tt_ttisgmt members of original elsie-code struct
since we don't support POSIX-style TZ descriptions in variables.
We don't use tt_ttisstd and tt_ttisgmt members of original elsie-code
struct since we don't support POSIX-style TZ descriptions in variables.
*/
} TRAN_TYPE_INFO;
......@@ -1337,6 +1335,7 @@ static MEM_ROOT tz_storage;
tz_storage. So contention is low.
*/
static pthread_mutex_t tz_LOCK;
static bool tz_inited= 0;
/*
This two static variables are inteded for holding info about leap seconds
......@@ -1410,7 +1409,6 @@ my_tz_init(THD *org_thd, const char *default_tzname, my_bool bootstrap)
my_bool return_val= 1;
int res;
uint not_used;
DBUG_ENTER("my_tz_init");
/*
......@@ -1436,6 +1434,7 @@ my_tz_init(THD *org_thd, const char *default_tzname, my_bool bootstrap)
}
init_alloc_root(&tz_storage, 32 * 1024, 0);
VOID(pthread_mutex_init(&tz_LOCK, MY_MUTEX_INIT_FAST));
tz_inited= 1;
/* Add 'SYSTEM' time zone to tz_names hash */
if (!(tmp_tzname= new (&tz_storage) TZ_NAMES_ENTRY()))
......@@ -1591,12 +1590,17 @@ end:
SYNOPSIS
my_tz_free()
*/
void my_tz_free()
{
VOID(pthread_mutex_destroy(&tz_LOCK));
hash_free(&offset_tzs);
hash_free(&tz_names);
free_root(&tz_storage, MYF(0));
if (tz_inited)
{
tz_inited= 0;
VOID(pthread_mutex_destroy(&tz_LOCK));
hash_free(&offset_tzs);
hash_free(&tz_names);
free_root(&tz_storage, MYF(0));
}
}
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment