maria-developers team mailing list archive

[Sergey Vojtovich <svoj@xxxxxxxxxxx>]

Hi Sergei,

I implemented all your suggestions. Could you take a look at updated patch?

Thanks,
Sergey

On Mon, Nov 25, 2013 at 09:17:02AM +0100, Sergei Golubchik wrote:
> Hi, Sergey!
> 
> On Nov 25, Sergey Vojtovich wrote:
> > > 
> > > Do we really want all these do-nothing compatibility options to show up
> > > in --help? May be not? The goal of this MDEV was not to fail with an
> > > error when starting on mysqld's my.cnf file, no one needs --help for
> > > that.
> > Agree. I just checked my_getopt sources and couldn't find easy way to hide
> > them. Do you have an idea how to hide them properly, or shall I just add
> > something like GET_HIDDEN flag?
> 
> GET_xxx normally specifies a type, like GET_DOUBLE.
> 
> In fact, sql_plugin.cc internally uses a convention that NULL in the
> comment field means that the option isn't displayed. We could do the
> same in my_getopt.
> 
> > > > === modified file 'storage/innobase/handler/ha_innodb.cc'
> > > > --- a/storage/innobase/handler/ha_innodb.cc	2013-11-13 21:58:19 +0000
> > > > +++ b/storage/innobase/handler/ha_innodb.cc	2013-11-20 11:37:53 +0000
> > > > @@ -15750,6 +15750,12 @@ static MYSQL_SYSVAR_BOOL(purge_stop_now,
> > > >    PLUGIN_VAR_OPCMDARG,
> > > >    "Set purge state to STOP",
> > > >    NULL, purge_stop_now_set, FALSE);
> > > > +
> > > > +static my_bool innodb_log_checkpoint_now;
> > > > +static MYSQL_SYSVAR_BOOL(log_checkpoint_now, innodb_log_checkpoint_now,
> > > > +  PLUGIN_VAR_OPCMDARG | PLUGIN_VAR_NOSYSVAR,
> > > > +  "MySQL 5.6 compatibility option. To be implemented in later 10.x versions.",
> > > > +  NULL, NULL, FALSE);
> > > >  #endif /* UNIV_DEBUG */
> > > 
> > > Why is that (and everything else in ha_innodb.cc) necessary?
> > > We'll merge with the latest InnoDB, we will have all its variables.
> > Same reason as for the other "to be implemented" options. Do you think there
> > is any difference?
> 
> Yes. For other options we need to made a conscious decision to merge the
> feature and then actually merge it. We might do it for some options and
> might not do it for others, on a case by case basis.
> 
> For InnoDB options we already decided that we will merge latest InnoDB
> changes. Thus we know for sure that all these options will be in 10.0.7,
> there is no place for "might not" or "case by case". Your changes will
> only cause merge conflicts.
> 
> Regards,
> Sergei
>