ourdelta-developers team mailing list archive

[Weldon Whipple <weldon@xxxxxxxxxxx>]

Hmmm... Just this past week we were bitten by this bug, and I found the fix
at:

https://code.launchpad.net/~d-launchpad-askneil-com/ourdelta/ourdelta-fix-bug338012

In sql/sql_show.cc, the structure ST_FIELD_INFO user_stats_fields_info[],
the first (USER) field had USERNAME_LENGTH for the length.

The following structure, ST_FIELD_INFO client_stats_fields_info[], had the
first (CLIENT) field had HOSTNAME_LENGTH for the length.

Then, in the file sql/structs.h, the definition of struct st_user_stats was
modivied to have the first field be of length HOSTNAME_LENGTH+1

I'm not sure if I found it in the "official" place, but I did find the
changes *somewhere* (i.e. at the above URL).

BTW, it fixed our "memory leak" (well, it behaved like a memory leak on
boxen with host names greater than 16 characters in length).

Weldon Whipple
weldon@xxxxxxxxxxx

On Fri, Sep 25, 2009 at 6:16 PM, Arjen Lentz <arjen@xxxxxxxxxxxxx> wrote:

> Hi Vadim
>
> On 26/09/2009, at 9:57 AM, Vadim Tkachenko wrote:
>
>> I think the patch is already included, isn't it ?
>>
>
> Nope, not in your lp 5.0.86 patch branch I just pulled.
> The situation is as described below, the USER field is not patched and the
> CLIENT field uses a different define.
>
> Cheers,
> Arjen.
>
>
>
>  On Fri, Sep 25, 2009 at 4:38 PM, Arjen Lentz <arjen@xxxxxxxxxxxxx> wrote:
>>
>>> Hi Vadim
>>>
>>> Please merge this in (sorry the paths are from the ourdelta tree, but the
>>> offset within the file is compatible with yours)
>>>
>>> === modified file 'mysql/5.0/percona_maintained/userstatv2.patch'
>>> --- mysql/5.0/percona_maintained/userstatv2.patch       2009-09-25
>>> 23:16:39
>>> +0000
>>> +++ mysql/5.0/percona_maintained/userstatv2.patch       2009-09-25
>>> 23:28:28
>>> +0000
>>> @@ -3901,7 +3901,7 @@
>>>
>>>  +ST_FIELD_INFO user_stats_fields_info[]=
>>>  +{
>>> -+  {"USER", 16, MYSQL_TYPE_STRING, 0, 0, "User"},
>>> ++  {"USER", USERNAME_LENGTH, MYSQL_TYPE_STRING, 0, 0, "User"},
>>>
>>>
>>>
>>> By the way, his fix for the CLIENT field was HOSTNAME_LENGTH (60) whereas
>>> you used LIST_PROCESS_HOST_LEN (64)
>>> In the mysql.user table the host field is a CHAR(60), so I'm guessing
>>> that
>>> Neil picked the correct macro.
>>> Harmless in this case, now, but might as well use the proper macro
>>> because
>>> if anything else changes later it could break.
>>>
>>
>
>
> --
> Arjen Lentz, Exec.Director @ Open Query (http://openquery.com)
> Exceptional Services for MySQL at a fixed budget.
>
> Follow our blog at http://openquery.com/blog/
> OurDelta: enhanced builds for MySQL @ http://ourdelta.org
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ourdelta-developers<https://launchpad.net/%7Eourdelta-developers>
> Post to     : ourdelta-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ourdelta-developers<https://launchpad.net/%7Eourdelta-developers>
> More help   : https://help.launchpad.net/ListHelp
>