Commit 714bf070 authored by unknown's avatar unknown
Browse files

Merge gbichot@bk-internal.mysql.com:/home/bk/mysql-3.23 

into mysql.com:/home/mysql_src/mysql-3.23
parents a18c4883 418fcdf1

sql/log_event.cc

+3 −5
Original line number Diff line number Diff line
@@ -302,13 +302,11 @@ void Start_log_event::print(FILE* file, bool short_form, char* last_db) 
    return;



  print_header(file);

  fprintf(file, "\tStart: binlog v %d, server v %s", binlog_version,

  fprintf(file, "\tStart: binlog v %d, server v %s created ", binlog_version,

	  server_version);

  print_timestamp(file);

  if (created)

  {

    fprintf(file, " created ");

    print_timestamp(file, &created);

  }

    fprintf(file," at startup");

  fputc('\n', file);

  fflush(file);

}

sql/log_event.h

+11 −0
Original line number Diff line number Diff line
@@ -335,6 +335,17 @@ class Start_log_event: public Log_event 
     by FLUSH LOGS or automatic rotation), 'created' should be 0.

     This "trick" is used by MySQL >=4.0.14 slaves to know if they must drop the

     stale temporary tables or not.

     Note that when 'created'!=0, it is always equal to the event's timestamp;

     indeed Start_log_event is written only in log.cc where the first

     constructor below is called, in which 'created' is set to 'when'. 

     So in fact 'created' is a useless variable. When it is 0

     we can read the actual value from timestamp ('when') and when it is

     non-zero we can read the same value from timestamp ('when'). Conclusion:

     - we use timestamp to print when the binlog was created.

     - we use 'created' only to know if this is a first binlog or not.

     In 3.23.57 we did not pay attention to this identity, so mysqlbinlog in

     3.23.57 does not print 'created the_date' if created was zero. This is now

     fixed.

  */

  time_t created;

  uint16 binlog_version;