Hello all, Does anyone have any feedback on this issue? We currently have a customer affected by this issue. Thanks -Zardosht On Tue, Jun 5, 2012 at 11:14 AM, Rich Prohaska wrote:

We made a slightly different change for MariaDB 5.5.24 in the TC_LOG_BINLOG::log_and_order function.

$ diff log.cc.orig log.cc 7424a7425,7426

...

  if (thd_get_ha_data(thd, binlog_hton) == NULL)     thd->binlog_setup_trx_data();

Is this correct?

Is this sufficient?

Thanks RIch Prohaska

On Tue, Jun 5, 2012 at 10:14 AM, Zardosht Kasheff wrote:

...

Hello all,

We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work?

-Zardosht

---------- Forwarded message ---------- From: Rich Prohaska Date: Mon, Jun 4, 2012 at 1:23 PM Subject: crash in slave replication with XA transaction To: internals@lists.mysql.com

Hello,

We are running MySQL 5.5.21 with both InnoDB and TokuDB as XA storage engines.  When one runs a transaction that inserts into an InnoDB table and a TokuDB table, the commit crashes the replication slave at log.cc line 6602 because cache_mngr == NULL.  We found a pattern in various log functions in log.cc that calls binlog_setup_trx_data to initialize the txn state.

This change fixes our immediate problem.

$ diff log.cc.orig log.cc 6595a6596,6597

...

  if (thd_get_ha_data(thd, binlog_hton) == NULL)     thd->binlog_setup_trx_data();

Is this a correct fix?  If so, are there other places that need a similar change?

Thanks Rich Prohaska

The transaction is: create table t1 (a int primary key) engine=innodb; create table t2 (a int primary key) engine=tokudb; set autocommit=0; insert into t1 values (1); insert into t2 values (2); commit;

the slave crashes while handling the commit binlog entry.

-- MySQL Internals Mailing List For list archives: http://lists.mysql.com/internals To unsubscribe:    http://lists.mysql.com/internals

Hello, Thanks for the feedback on how to fix our replication slave crash. I hacked the mariadb 5.5.23 and ended up with the attached patch. Rich Prohaska On Fri, Jun 8, 2012 at 1:37 PM, Michael Widenius wrote:

Hi!

...

...

...

...

...

"Zardosht" == Zardosht Kasheff writes:

Zardosht> Hello all, Zardosht> We see this on Maria 5.2 and Maria 5.5 as well. Does the following fix work?

Zardosht> -Zardosht

<cut> Zardosht> We are running MySQL 5.5.21 with both InnoDB and TokuDB as XA storage Zardosht> engines. When one runs a transaction that inserts into an InnoDB Zardosht> table and a TokuDB table, the commit crashes the replication slave at Zardosht> log.cc line 6602 because cache_mngr == NULL. We found a pattern in Zardosht> various log functions in log.cc that calls binlog_setup_trx_data to Zardosht> initialize the txn state.

Zardosht> This change fixes our immediate problem.

Zardosht> $ diff log.cc.orig log.cc Zardosht> 6595a6596,6597

...

...

if (thd_get_ha_data(thd, binlog_hton) == NULL) thd->binlog_setup_trx_data();

Zardosht> Is this a correct fix? If so, are there other places that need a Zardosht> similar change?

I would just add a call to

if (thd->binlog_setup_trx_data()) DBUG_RETURN(1);

Just before calling:

binlog_cache_mngr *cache_mngr= (binlog_cache_mngr*) thd_get_ha_data(thd, binlog_hton);

There is no need to test for value of thd_get_ha_data(thd,binlog_hton) as the function thd->binlog_setup_trx_data() already does that.

There is a couple of other functions that also calls thd_get_ha_data(thd, binlog_hton) and uses this without checking if the value returned is == NULL . You probably want to add the same code in these functions.

Regards, Monty