Jan Lindström <[email protected]> writes: > static int binlog_savepoint_set(handlerton *hton, THD *thd, void *sv) > {
> #ifdef WITH_WSREP > if (wsrep_emulate_bin_log) DBUG_RETURN(0); > #endif /* WITH_WSREP */ > > wsrep_emulate_bin_log = 1, thus no savepoint is written to bin log Ah, I missed that. Right, then I think the problem is clear. In binlog_savepoint_set(), we do at the end to initialise *sv: binlog_trans_log_savepos(thd, (my_off_t*) sv); Then in binlog_savepoint_rollback() we read back the value that binlog_savepoint_set() put in: binlog_trans_log_truncate(thd, *(my_off_t*)sv); But the handling of WITH_WSREP and wsrep_emulate_bin_log=1 is done incorrectly. Because in this case the initialisation in binlog_savepoint_set() is disabled, but the value is still used in binlog_savepoint_rollback() (the access is outside of if (!wsrep_emulate_bin_log && ...). So this is clearly a problem with the WSREP patch related to savepoints. I am not familiar with how that is supposed to work, so now you need to ask the Codership people how this is supposed to work. Either binlog_savepoint_rollback() should not access *sv in the wsrep_emulate_bin_log case, or alternatively binlog_savepoint_set() _should_ initialise *sv in this case. > Thanks for the help, I do not seem to be able to run with that > --debug=d,*:t:i > setup, it does not seem to progress. Maybe it is just slow (especially if you also had Valgrind enabled), it will generate lots and lots of output. - Kristian. _______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
