List:Internals« Previous MessageNext Message »
From:Dmitry Lenev Date:May 14 2009 6:58pm
Subject:Re: Review of "FLUSH TIMEZONES"
View as plain text  
Hello Mark!

* Mark Leith <leith@stripped> [09/05/01 15:29]:
> On 30 Apr 2009, at 13:50, Dmitry Lenev wrote:
>> * Guilhem Bichot <guilhem@stripped> [09/04/30 16:22]:
>>> - There are also mysql.time* tables: assume the user fixed them with
>>> "mysql_tzinfo_to_sql /usr/share/zoneinfo"; Sveta tells me that mysqld
>>> notices the new content automatically (no need for a mysqld  
>>> restart), so
>>> FLUSH TIMEZONES needn't do anything to reload those tables?
>> Sveta is only partially right. Yes, server notices definitions of new
>> time zones (i.e. time zones which didn't exist or was not ever used by
>> clients before) automatically and no server restart is needed.
>> But it won't automatically notice change in definition of already
>> existing time zone that was used at least once since server start-up.
>> The old definition will be used until server restart.
>> So certainly there is some work to do if one wants FLUSH TIMEZONES to
>> affect non-SYSTEM time zones as well.
> Do you have any pointers on what I should do to make this work?

As minimum we have to ensure that FLUSH TIMEZONES removes old time zone
definitions from the cache implemented by tz_names hash (see,
so after this statement new definitions are loaded into cache.

Then we probably want to ensure that old definitions are removed from
the memory once they are no longer used. To achieve this we probably
will have to implement some form of reference counting and therefore
change interface of timezone subsystem to use a pair of my_tz_get()/
my_tz_release() calls instead of current one my_tz_find() call.

Finally, we might want to consider the effects of FLUSH TIMEZONES on
replication and binary log. If we want to ensure that this operation
is safe for statement-based replication then probably it has to wait
until all statements that use old time zones are finished (actually
if we want this properly work for transactions it has to wait until
all transactions which use old time zones are finished). 
Alternatively we can ask users to switch to row-based mode for the
duration of this statement (although the only safe way to do this
which comes to my mind involves taking a global read lock, setting
global variable for binlogging mode to row-based and killing all

What is your opinion about this?

Dmitry Lenev, Software Developer

Are you MySQL certified?
Re: Review of "FLUSH TIMEZONES"( Lenev14 May