Re: [Maria-developers] [Commits] a8162d4: MDEV-9312: storage engine not enforced during galera cluster replication
Hi, Nirbhay! I don't understand, why do you need to create a dummy plugin here? On Sep 27, Nirbhay Choubey wrote:
revision-id: a8162d4a8737cff67889390fad0153acc175391d (mariadb-10.1.17-22-ga8162d4) parent(s): 6a6b253a6ecbd4d3dd254044d12ec64475453275 author: Nirbhay Choubey committer: Nirbhay Choubey timestamp: 2016-09-27 09:03:26 -0400 message:
MDEV-9312: storage engine not enforced during galera cluster replication
Perform a post initialization of plugin-related variables of wsrep threads after their global counterparts have been initialized. ... +#ifdef WITH_WSREP + +/* + Placeholder for global_system_variables.table_plugin required during + initialization of startup wsrep threads. +*/ +static st_plugin_int *wsrep_dummy_plugin; + +/* + Initialize wsrep_dummy_plugin and assign it to + global_system_variables.table_plugin. +*/ +void wsrep_plugins_pre_init() +{ + wsrep_dummy_plugin= + (st_plugin_int *) my_malloc(sizeof(st_plugin_int), MYF(0)); + wsrep_dummy_plugin->state= PLUGIN_IS_DISABLED; + global_system_variables.table_plugin= plugin_int_to_ref(wsrep_dummy_plugin); +} + Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi Serg, On Tue, Sep 27, 2016 at 3:49 PM, Sergei Golubchik <serg@mariadb.org> wrote:
Hi, Nirbhay!
I don't understand, why do you need to create a dummy plugin here?
Since global_system_variables.table_plugin is null when the startup wsrep threads are created, I used dummy plugin to initialize it to avoid running into segfaults in intern_plugin_lock() invoked from under plugin_thdvar_init(). static plugin_ref intern_plugin_lock(LEX *lex, plugin_ref rc) { st_plugin_int *pi= plugin_ref_to_int(rc); ... if (pi->state & (PLUGIN_IS_READY | PLUGIN_IS_UNINITIALIZED | PLUGIN_IS_DELETED)) Also, with this commit plugin_thdvar_init() is free from wsrep related changes. Best, Nirbhay
revision-id: a8162d4a8737cff67889390fad0153acc175391d (mariadb-10.1.17-22-ga8162d4) parent(s): 6a6b253a6ecbd4d3dd254044d12ec64475453275 author: Nirbhay Choubey committer: Nirbhay Choubey timestamp: 2016-09-27 09:03:26 -0400 message:
MDEV-9312: storage engine not enforced during galera cluster replication
Perform a post initialization of plugin-related variables of wsrep threads after their global counterparts have been initialized. ... +#ifdef WITH_WSREP + +/* + Placeholder for global_system_variables.table_plugin required during + initialization of startup wsrep threads. +*/ +static st_plugin_int *wsrep_dummy_plugin; + +/* + Initialize wsrep_dummy_plugin and assign it to + global_system_variables.table_plugin. +*/ +void wsrep_plugins_pre_init() +{ + wsrep_dummy_plugin= + (st_plugin_int *) my_malloc(sizeof(st_plugin_int), MYF(0)); + wsrep_dummy_plugin->state= PLUGIN_IS_DISABLED; + global_system_variables.table_plugin= plugin_int_to_ref(wsrep_dummy_
On Sep 27, Nirbhay Choubey wrote: plugin);
+} + Regards, Sergei Chief Architect MariaDB and security@mariadb.org
Hi, Nirbhay! On Sep 27, Nirbhay Choubey wrote:
On Tue, Sep 27, 2016 at 3:49 PM, Sergei Golubchik <serg@mariadb.org> wrote:
I don't understand, why do you need to create a dummy plugin here?
Since global_system_variables.table_plugin is null when the startup wsrep threads are created, I used dummy plugin to initialize it to avoid running into segfaults in intern_plugin_lock() invoked from under plugin_thdvar_init().
static plugin_ref intern_plugin_lock(LEX *lex, plugin_ref rc) { st_plugin_int *pi= plugin_ref_to_int(rc); ... if (pi->state & (PLUGIN_IS_READY | PLUGIN_IS_UNINITIALIZED | PLUGIN_IS_DELETED))
I see.
Also, with this commit plugin_thdvar_init() is free from wsrep related changes.
That's great, indeed! I'd probably declared wsrep_dummy_plugin statically, instead of allocating it: static st_plugin_int wsrep_dummy_plugin; but it doesn't matter much in this bug fix, so whatever you prefer. Ok to push Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Nirbhay Choubey -
Sergei Golubchik