← Back to team overview

maria-developers team mailing list archive

Re: b22a28c2295: fixup! 3fe5cd5e1785e3e8de7add9977a1c2ddd403538b

 

Hi!

On Wed, May 20, 2020 at 8:14 PM Sergei Golubchik <serg@xxxxxxxxxxx> wrote:
<cut>

> > MDEV-22607 Assertion `ha_info->ht() != binlog_hton' failed in
> >            MYSQL_BIN_LOG::unlog_xa_prepare
> >
> > diff --git a/sql/log.cc b/sql/log.cc
> > index 7e9e231358a..792c6bb1a99 100644
> > --- a/sql/log.cc
> > +++ b/sql/log.cc
> > @@ -10128,11 +10128,6 @@ int TC_LOG_BINLOG::unlog_xa_prepare(THD *thd, bool all)
> >      if (rw_count > 0)
> >      {
> >        /* an empty XA-prepare event group is logged */
> > -#ifndef DBUG_OFF
> > -      for (ha_info= thd->transaction->all.ha_list; rw_count > 1 && ha_info;
> > -           ha_info= ha_info->next())
> > -        DBUG_ASSERT(ha_info->ht() != binlog_hton);
> > -#endif
> >        rc= write_empty_xa_prepare(thd, cache_mngr); // normally gains need_unlog
> >        trans_register_ha(thd, true, binlog_hton, 0); // do it for future commmit
> >      }
>
> What does this assertion mean and what does it mean that it no longer
> holds?

As far as I understand it was always wrong and didn't make sense.  The
reason it was not hit
is that before Aria was not treated as transactional we could only
come here in case of errors
and that code was was apparently not tested, at least with binary logging on.

With Aria we could come here in case of rollback and we got assert for
cases that was perfectly ok.

Regards,
Monty


References