List:Internals« Previous MessageNext Message »
From:Mark Leith Date:June 5 2009 12:24pm
Subject:Fwd: mailing list issue [Fwd: Re: Review of "FLUSH TIMEZONES"
(http://forge.mysql.com/worklog/task.php?id=4908)]
View as plain text  
/me stabs the list and tries to send again

Begin forwarded message:

> From: Mark Leith <mark.leith@stripped>
> Date: 5 June 2009 12:01:26 BST
> To: Guilhem Bichot <guilhem@stripped>
> Cc: internals <internals@stripped>, Dmitry Lenev
> <dmitri.lenev@stripped 
> >
> Subject: Re: mailing list issue [Fwd: Re: Review of "FLUSH  
> TIMEZONES" (http://forge.mysql.com/worklog/task.php?id=4908)]
>
> Hi Guilhem,
>
> On 3 Jun 2009, at 22:22, Guilhem Bichot wrote:
>
>> Hey Marc,
>>
>> while creating BUG#45312 (a bit of bureaucracy, don't bother), I  
>> noticed that I didn't find your emails cc:ed to internals (like the  
>> one below) into the archive of this list: neither in
> http://lists.mysql.com/internals?thread=2009-05
>> nor in
>> http://lists.mysql.com/internals?thread=2009-04
>> Does your system have trouble sending to them (I sometimes got  
>> bounces from commits@lists for my messages)? Or should be bring  
>> this up with the sysadmins for fixing?
>> Thanks!
>
>
> I had problems initially because my mail client was set to send from  
> "leith@stripped" instead of "mark.leith@stripped" which the list has  
> my subscription as. I changed it - so it should be OK now (I copied  
> the list to check).
>
> I had missed Dmitri's reply though - so thanks for pinging me.
>
> I don't think replication is an issue because I disabled logging it  
> to the binary log, but the other concerns do sound valid. Given the  
> extra work however - I'm not really sure when I'll get the time to  
> do this now given other priorities.
>
> I do have it on my TODO for clean up however, so hopefully I can get  
> back to it. I'd suggest chasing other contributions in the interim. :)
>
> Thanks for the poke.
>
> Regards
>
> Mark
>
>
>> -------- Message original --------
>> Sujet: 	Re: Review of "FLUSH TIMEZONES"
>> (http://forge.mysql.com/worklog/task.php?id=4908)
>> Date: 	Fri, 01 May 2009 12:27:57 +0100
>> De: 	Mark Leith <leith@stripped>
>> Pour :: 	Guilhem Bichot <guilhem@stripped>
>> Copie à :: 	internals <internals@stripped>
>> Références: 	<49F971D6.7020108@stripped>
>>
>>
>>
>> Hi Guilhem,
>>
>> Thanks for looking at this!
>>
>> On 30 Apr 2009, at 10:39, Guilhem Bichot wrote:
>>
>>> Hi Mark,
>>>
>>> Here are comments about your patch:
>>>
>>> ===== sql/sql_parse.cc 1.605 vs edited =====
>>> @@ -6943,6 +6943,11 @@
>>>
>>> #endif
>>>
>>> if (options & REFRESH_USER_RESOURCES)
>>>
>>>   reset_mqh((LEX_USER *) NULL);
>>>
>>> + if (options & REFRESH_TIMEZONES)
>>>
>>> + {
>>>
>>> +   tmp_write_to_binlog= 0;
>>>
>>> Ok, sending it to 100 slaves may slow them down, and it's unlikely  
>>> that their OS timezone files are upgraded in sync.
>>
>>
>> Indeed, that was my main reason for doing this. We do it on a few  
>> of the
>> other FLUSH commands too, for varying reasons, from what I see in  
>> the code.
>>
>>
>>> +   tzset();
>>>
>>> - Ok, that's for reloading the OS' timezone.
>>> - tzset() is supposed to set a global string "extern char  
>>> *tzname[2]" used by some time functions; assuming thread1 calls  
>>> tzset() while thread2 is using a time function, could it be that  
>>> thread1 is overwriting tzname[2] while thread2 is reading the  
>>> content of tzname[2] and thus, thread2 would get read garbage?  
>>> (half-overwritten array)?
>>
>>
>> *Apparently* tzset() is thread safe. I did a little checking on the  
>> net
>> around this, and came across a few things like this:
>>
>> http://theopengroup.org/austin/mailarchives/ag/msg02479.html
>>
>> http://www.rdg.ac.uk:8081/cgi-bin/cgiwrap/wsi14/poplog/man/3C/ctime
>>
>> "The ctime_r(), localtime_r(), and tzset() functions are MT-Safe in
>> multithread applications, as long as no user-defined function  
>> directly
>> modifies one of the following variables: timezone, altzone, daylight,
>> and tzname. These four variables are not MT-Safe to access. They are
>> modified by the tzset() function in an MT-Safe manner. The mktime(),
>> localtime_r(), and ctime_r() functions call tzset()."
>>
>>
>>> - what happens to sessions which started before FLUSH TIMEZONES  
>>> was called: do they continue using the old timezone info? do they  
>>> risk problems?
>>
>>
>> From my monkey testing this acts like changing a global variable (new
>> connections get it, currents ones do not).
>>
>>
>>> - 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?
>>
>>
>> I see Dmitri's reply as well - I'll respond on that to this.
>>
>> Best regards
>>
>> Mark
>>
>> -- 
>> Mark Leith
>> MySQL Regional Support Manager, Americas
>> Sun Microsystems, Inc., http://www.sun.com/mysql/
>>
>>
>>
>>
>>
>> -- 
>> Mr. Guilhem Bichot <guilhem@stripped>
>> Sun Microsystems / MySQL, Lead Software Engineer
>> Bordeaux, France
>> www.sun.com / www.mysql.com
>
> -- 
> Mark Leith
> MySQL Regional Support Manager, Americas
> Sun Microsystems, Inc., http://www.sun.com/mysql/
>
>
>
>

-- 
Mark Leith
MySQL Regional Support Manager, Americas
Sun Microsystems, Inc., http://www.sun.com/mysql/




Thread
Fwd: mailing list issue [Fwd: Re: Review of "FLUSH TIMEZONES"(http://forge.mysql.com/worklog/task.php?id=4908)]Mark Leith5 Jun