Jan Lindström <jplindst@mariadb.org> 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.