Hi!
On Sep 7, 2007, at 4:15 PM, Chad MILLER wrote:
> What's the master_delay global variable for? Here's how I see it
> used, with "grep".
>
> +uint32 master_delay= 0;
> + mi->delay= master_delay;
> + /* added value of master_delay */
> + init_intvar_from_file(&delay, &mi->file, master_delay))
> +extern uint32 master_delay;
>
> Perhaps it's the first step in something you're planning to submit?
Actually, it's the heart of the patch and it should be complete in
itself.
master_delay is the value that's being read in from the master.info
file, like the other members of the mi object.
I mimicked the naming scheme of the other values read from
master.info. Everything coming from that file is
global and has 'master_' prepended to the actual member name as it is
declared in class MASTER_INFO.
It eventually ends up as the delay member (second line in your grep
output) and that's what is subsequently used in
the SQL thread of the replication.
The other way the value of delay can come into mysql is the lexer
(via lex_my->delay). It directly sets
mi->delay and then it gets written out into master.info.
As I have no idea what structures you have (or planning to have) for
multi-master replication, master_delay is global right now.
For multi-master replication this obviously has to go into the
correct struct for that particular master. There's
no need for it to be global per se, although this is the way all
master.info values are currently handled.
> Since the patch came with no test, I took the time to create one.
> Here's my first try of a test file.
>
> I welcome ideas for new tests or implementations of the ideas at
> the end. I want to prove that there are no bugs or unexpected
> behavior in adding this feature. Help!
As soon as I have a minute I will try to set up a test case based
upon yours. What version of the tree are you integrating this into?
Maybe I can start off of that to help out. The patch was against
mysql-5.1-bk (from June 6th, I guess), so it's rather oldish.
cheers,
-k
--
Kay Röpke
http://classdump.org/
