Merge with 3.23 tree to get latest bug fixes

BitKeeper/etc/logging_ok:
  auto-union
sql/item_func.cc:
  Auto merged
mysql-test/t/user_var.test:
  Auto merged
sql/log_event.cc:
  Auto merged
sql/log_event.h:
  Auto merged
sql/nt_servc.cc:
  Auto merged
configure.in:
  Use local version
innobase/os/os0file.c:
  Use local version
innobase/page/page0page.c:
  Use local version
innobase/row/row0sel.c:
  Use local version
innobase/row/row0vers.c:
  Use local version
mysql-test/r/order_by.result:
  Use local version
mysql-test/r/user_var.result:
  merge with 3.23
mysql-test/t/order_by.test:
  Use local version (test is already in range.test)
sql/log.cc:
  Use local version
sql/share/spanish/errmsg.txt:
  merge
sql/slave.cc:
  Use local version
sql/sql_class.h:
  Use local version
sql/sql_select.cc:
  Use patch in 4.0 for range with NULL problem

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];