Merge with 3.23 tree to get latest bug fixes

1 files changed, 20 insertions, 0 deletions

diff --git a/sql/log_event.h b/sql/log_event.h
index 4b32894d787..a55efffa319 100644
--- a/sql/log_event.h
+++ b/sql/log_event.h
@@ -452,6 +452,26 @@ extern char server_version[SERVER_VERSION_LENGTH];
 class Start_log_event: public Log_event
 {
 public:
+  /* 
+     If this event is at the start of the first binary log since server startup
+     'created' should be the timestamp when the event (and the binary log) was
+     created. 
+     In the other case (i.e. this event is at the start of a binary log created
+     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;
   char server_version[ST_SERVER_VER_LEN];