Re: bzr commit into mysql-5.1-bugteam branch (davi:3520) Bug#42054

[Davi Arnaut]

On 12/16/10 8:11 AM, Dmitry Lenev wrote:
> Hello Davi!
>
> * Davi Arnaut<davi.arnaut@stripped>  [10/12/16 12:26]:
>> On 12/16/10 5:21 AM, Dmitry Lenev wrote:
>>> Hello Davi!
>>>
>>> * Davi Arnaut<davi.arnaut@stripped>   [10/12/14 02:35]:
>>>> # At a local mysql-5.1-bugteam repository of davi
>>>>
>>>>    3520 Davi Arnaut	2010-12-13
>>>>         Bug#42054: SELECT CURDATE() is returning bad value
>>>
>>> ...
>>>
>>>>         Since this logic was being used due to ancient performance
> reasons,
>>>>         the solution is to simply rely on time(), which nowadays is just
> a
>>>>         wrapper around the somewhat fast gettimeofday function.
>>>
>>> Could you please elaborate when has this change occurred and what
>>> has changed?
>>
>> I didn't look up the history. What I had found was this:
>>
>> http://tinyurl.com/38bqrmq
>>
>> Where time() is mapped to a gettimeofday.
>>
>> But now I see that there is another time implementation:
>>
>> http://tinyurl.com/282rn6n
>>
>> that calls the time system call.
>>
>> We need to find out what is the difference between libbc and libc.
>
> http://www.mail-archive.com/opensolaris-code@ style="color:#666">stripped/msg00781.html
>
> Says that 'libbc is the "backward compatibility" library which is
> present only on SPARC; it's a C library in Solaris native format but
> implementing the SunOS 4.x runtime'.
>
> So AFAIU it is not the thing which is used by default.
>
>>> Looking at OpenSolaris sources (yes, I know it is discontinued) I still
>>> can see that time() uses systrap whereas gethrtime() uses something which
>>> is called *fast*" systrap.
>>
>> gettimeofday also uses a "fast" systrap:
>>
>> http://tinyurl.com/296f2vq
>>
>>> Also I have found the following article claiming that using gethrtime
>>> gives boost to MySQL performance even on Solaris 10:
>>>
>>> http://developers.sun.com/solaris/articles/mysql_perf_tune.html
>>
>> I find this article highly suspicious since this hack exist at least
>> since July of 2007. Also, obviously, the explanation there is simply
>> wrong as we _can't_ use gethrtime for timing.
>
> Well, it is not very clear when this article was written.
>
> But it seems to be focused on MySQL 5.0 which AFAICS doesn't
> include this particular hack. This can explain its results.
>
> I agree that explanation is somewhat confusing. But in the end
> I think the suggestion in article boils down to using time()
> implementation which is based on gethrtime() similarly to
> hack in out code. This is achieved by linking MySQL with
> -lfasttime library described at
> http://developers.sun.com/solaris/articles/time_stamp.html.

Similar in the sense that it has the same bug and is not thread safe -- 
the MySQL one is wrapper inside a mutex.

How about we ask the benchmark team to actually measure this patch?

>>
>>> And finally please note that for 5.1 we still support Solaris 8 and 9:
>>>
>>> http://www.mysql.com/support/supportedplatforms/database.html
>>>
>>
>> What is your point?
>
> My point was that if, for example, time() became fast only starting from
> Solaris 10, we could not simply remove this hack from 5.1, as it would make
> MySQL 5.1 slower on one of its supported platforms.
>

Yes, but we still need to fix the bug, don't we? The hack is wrong.
Also, in the worst case, we could simply use gettimeofday.

Regards,

Davi