Commit d4a7867a authored by unknown's avatar unknown

Reorder struct elements to be more optimal for 64 bit computers

(Main reason for reordering was to get rid of compiler warnings for order of element initialization)


sql/log.cc:
  Remove compiler warning
sql/sql_class.h:
  Reorder MYSQL_LOG struct elements to be more optimal for 64 bit computers
  (Main reason for reordering was to get rid of compiler warnings for order of element initialization)
parent 29e07bcb
......@@ -356,9 +356,10 @@ static int find_uniq_filename(char *name)
MYSQL_LOG::MYSQL_LOG()
:bytes_written(0), last_time(0), query_start(0), name(0),
file_id(1), open_count(1), log_type(LOG_CLOSED), write_error(0), inited(0),
need_start_event(1), prepared_xids(0), description_event_for_exec(0),
description_event_for_queue(0), readers_count(0), reset_pending(FALSE)
prepared_xids(0), log_type(LOG_CLOSED), file_id(1), open_count(1),
readers_count(0), reset_pending(FALSE), write_error(FALSE), inited(FALSE),
need_start_event(TRUE),
description_event_for_exec(0), description_event_for_queue(0)
{
/*
We don't want to initialize LOCK_Log here as such initialization depends on
......
......@@ -190,10 +190,10 @@ class MYSQL_LOG: public TC_LOG
private:
/* LOCK_log and LOCK_index are inited by init_pthread_objects() */
pthread_mutex_t LOCK_log, LOCK_index, LOCK_readers;
pthread_mutex_t LOCK_prep_xids;
pthread_cond_t COND_prep_xids;
pthread_cond_t update_cond;
pthread_cond_t reset_cond;
bool reset_pending;
int readers_count;
ulonglong bytes_written;
time_t last_time,query_start;
IO_CACHE log_file;
......@@ -201,21 +201,6 @@ class MYSQL_LOG: public TC_LOG
char *name;
char time_buff[20],db[NAME_LEN+1];
char log_file_name[FN_REFLEN],index_file_name[FN_REFLEN];
// current file sequence number for load data infile binary logging
uint file_id;
uint open_count; // For replication
volatile enum_log_type log_type;
enum cache_type io_cache_type;
bool write_error, inited;
bool need_start_event;
/*
no_auto_events means we don't want any of these automatic events :
Start/Rotate/Stop. That is, in 4.x when we rotate a relay log, we don't want
a Rotate_log event to be written to the relay log. When we start a relay log
etc. So in 4.x this is 1 for relay logs, 0 for binlogs.
In 5.0 it's 0 for relay logs too!
*/
bool no_auto_events;
/*
The max size before rotation (usable only if log_type == LOG_BIN: binary
logs and relay logs).
......@@ -227,13 +212,38 @@ class MYSQL_LOG: public TC_LOG
fix_max_relay_log_size).
*/
ulong max_size;
ulong prepared_xids; /* for tc log - number of xids to remember */
pthread_mutex_t LOCK_prep_xids;
pthread_cond_t COND_prep_xids;
volatile enum_log_type log_type;
enum cache_type io_cache_type;
// current file sequence number for load data infile binary logging
uint file_id;
uint open_count; // For replication
int readers_count;
bool reset_pending;
bool write_error, inited;
bool need_start_event;
/*
no_auto_events means we don't want any of these automatic events :
Start/Rotate/Stop. That is, in 4.x when we rotate a relay log, we don't
want a Rotate_log event to be written to the relay log. When we start a
relay log etc. So in 4.x this is 1 for relay logs, 0 for binlogs.
In 5.0 it's 0 for relay logs too!
*/
bool no_auto_events;
friend class Log_event;
public:
/*
These describe the log's format. This is used only for relay logs.
_for_exec is used by the SQL thread, _for_queue by the I/O thread. It's
necessary to have 2 distinct objects, because the I/O thread may be reading
events in a different format from what the SQL thread is reading (consider
the case of a master which has been upgraded from 5.0 to 5.1 without doing
RESET MASTER, or from 4.x to 5.0).
*/
Format_description_log_event *description_event_for_exec,
*description_event_for_queue;
MYSQL_LOG();
/*
note that there's no destructor ~MYSQL_LOG() !
......@@ -246,18 +256,6 @@ class MYSQL_LOG: public TC_LOG
int log(THD *thd, my_xid xid);
void unlog(ulong cookie, my_xid xid);
int recover(IO_CACHE *log, Format_description_log_event *fdle);
/*
These describe the log's format. This is used only for relay logs.
_for_exec is used by the SQL thread, _for_queue by the I/O thread. It's
necessary to have 2 distinct objects, because the I/O thread may be reading
events in a different format from what the SQL thread is reading (consider
the case of a master which has been upgraded from 5.0 to 5.1 without doing
RESET MASTER, or from 4.x to 5.0).
*/
Format_description_log_event *description_event_for_exec,
*description_event_for_queue;
void reset_bytes_written()
{
bytes_written = 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