List:Commits« Previous MessageNext Message »
From:Mats Kindahl Date:June 3 2008 1:10pm
Subject:Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998
View as plain text  
Andrei Elkin wrote:
> Mats, hello.
> 
> Just have committed a new cset which account remained from the last
> round issues.
> Besides, i changed IGNORE_SERVER_ID -> IGNORE_SERVER_IDS in the parser
> as the argument for the paramenter is a list.
> And there is one optimization for slave.cc's filtering out rule.
> I could not make it looking any simpler though.
> 
> 
> 
>>> 1. this bug issue voting agenda:
>>>
>>>    Shall we enforce that a new option to CHANGE MASTER will survive
>>>    reset master. I.e at the end of the following sequence of queries
>>>    
>>>    change master ignore_server_id=(1,2,3);
>>>    reset master;
>>>    start master;
>>>
>>>    wrt to the current IGNORE_SERVER_ID option we shall have either:
>>>
>>>    SHOW SLAVE STATUS like `ignore_server_id' => 1,2,3
>>>
>>>    or another alternative
>>>
>>>    SHOW SLAVE STATUS like `ignore_server_id' => empty
>> I vote that the list shall behave uniformly to how the other options
>> work: i.e., being retained over resets (without an intervening shutdown).
>>
> 
> I have mailed with explanations that I change my vote for persistency
> (of ignore_server_ids i.e :-).
> Therefore a hunk dealing with resetting the ignored list gets removed.
> Wrt to how else to reset the list, it's pretty simple - the empty rhs for
> IGNORE_SERVER_ID=().

OK. Good.

>>>>>>>   sql/rpl_mi.cc@stripped, 2008-05-08 21:00:32+03:00,
> aelkin@stripped +67 -4
>>>>>>>     initialization, storing into master info, reading from
> the file, deallocation
>>>>>>>     of the list of ignored server id:s.
>>>>>>>   
>>>>>> "initialization"? What did you do here?
>>>>>> "storing into master info"? Storing what into master info? What
> did
>>>>>> you do here?
>>>>>> "reading from the file"? What file? What did you do here?
>>>>>>
>>>>> I am lost in the number of questions...
>>>>>
>>>>> I seriously doubt you had a hard time to find out what is supposed to
> be
>>>>> stored into, read from the master info file :-)
>>>>> Besides, it's said explicitly at the end of the clause - "of the
> list
>>>>> of ignored server id:s". The latter is the common object of several
>>>>> operations mentioned in the comment clause.
>>>>>
>>>>> One point of your critique I have to accept:
>>>>> "initialization" meant allocation actually (of what is said at the
> end of the
>>>>> clause). (todo)
>>>>>
>>>>> Yes, there is yet another initialization. Of the new `master_id'
>>>>> member of Master_info.
>>>>> That's not said. Neither it is worth to mention as there is the
> source
>>>>> of the patch.
>>>>>
>>>>> "Reading from the file" means reading from a file that was last time
>>>>> mentioned.
>>>>>
>>>>> "What did you do here?" obviously, the slave reads from the master
>>>>> info file, the new line with the ignored server id list.
>>>> The point is that the comment is a fragment and does not make any sense
>>>> as it stands. I would prefer if you could write out the comment so that
>>>> it makes sense without having to look at the code.
>>> It's too strong requirement to provide comments eliminating need to
>>> look as the source code. Comments are by the definition a part of it.
>>> In my opinion, none, incl a reviewer, can demand such service as
>>> release from reading the sources.
>> You're nitpicking: the comment should be readable. It serves no purpose
>> otherwise when you browse the file history, which is what the comment is
>> used for.
> 
> The worst thing if we both would be nitpickers ...
> More than correcting "initialization" (of what) I have extended
> sql/rpl_mi.cc snippet of comments.

The problem was the fact that the comment was not comprehensible and not
any individual spelling or grammar, I don't view that as nitpicking.

> 
> Please find it in a new cset.

Yes, I noted it. It is much better.

> 
> 
>> [snip]
>>
>>>> I would say that it is expected that after master-slave.inc has been
>>>> executed, test is ready to run, including that the slave has started.
>>>>
>>>> I would prefer you could add that line to master-slave.inc instead.
>>> Well, two things.
>>>
>>> The main, i did not notice last time that it's not the test of SQL thread
>>>
>>>   include/wait_for_slave_to_start.inc 
>>>
>>> but synchronization with the master
>>>
>>>   sync_slave_with_master;
>>>
>>> which was meant, sorry.
>>>
>>> Second is a footnote{it would not be instead. "Instead" would be to do that
>>> in `start slave' handler because that suffice to
>>> `include/master-slave.inc', not vice versa}
>> Are you saying that you will add the line to master-slave.inc instead or
>> not?
> 
> I added the line with
> 
>    sync_slave_with_master
> 
> to include/master-slave.inc

OK.

Just my few cents,
Mats Kindahl

-- 
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com

Thread
bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Andrei Elkin8 May 2008
  • Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Mats Kindahl20 May 2008
    • Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Andrei Elkin22 May 2008
      • Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Mats Kindahl28 May 2008
        • Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Andrei Elkin30 May 2008
          • Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Mats Kindahl2 Jun 2008
Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Andrei Elkin3 Jun 2008
  • Re: bk commit into 6.0 tree (aelkin:1.2634) BUG#25998Mats Kindahl3 Jun 2008