From 98f57fbe955f73c7c8111b10ff21c675d2f577d9 Mon Sep 17 00:00:00 2001 From: unknown Date: Fri, 6 Jun 2003 13:52:15 +0200 Subject: -- already approved; it would be nice if it goes into 3.23.57 -- Fix for bug 254 : the first Start_log_event after server startup will have created=now(), whereas the next ones (FLUSH LOGS, auto rotation) will have created=0. Before this, it was always now(). This way, slaves >=4.0.14 will know when they must drop stale temp tables or not. The next task is now modify 4.0.14 to implement this. sql/log.cc: Fix for bug 254 : the first Start_log_event after server startup will have created=now(), whereas the next ones (FLUSH LOGS, auto rotation) will have created=0. Before this, it was always now(). This way, slaves >=4.0.14 will know when they must drop stale temp tables or not. sql/log_event.h: An explanation. sql/sql_class.h: Prototype change (see log.cc). --- sql/log_event.h | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'sql/log_event.h') diff --git a/sql/log_event.h b/sql/log_event.h index 68696442490..bb1c9260e21 100644 --- a/sql/log_event.h +++ b/sql/log_event.h @@ -327,6 +327,15 @@ 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. + */ time_t created; uint16 binlog_version; char server_version[50]; -- cgit v1.2.1