Comment 1 for bug 1412693

So, what is the bug here? Undocumented "ROLLING BACK" message? Or the fact that transaction continued?

I see the following in the code:

trx_get_que_state_str(
/*==================*/
        const trx_t* trx) /*!< in: transaction */
{
        /* be sure to adjust TRX_QUE_STATE_STR_MAX_LEN if you change this */
        switch (trx->lock.que_state) {
        case TRX_QUE_RUNNING:
                return("RUNNING");
        case TRX_QUE_LOCK_WAIT:
                return("LOCK WAIT");
        case TRX_QUE_ROLLING_BACK:
                return("ROLLING BACK");
        case TRX_QUE_COMMITTING:
                return("COMMITTING");
        default:
                return("UNKNOWN");
        }
}

And then:

Percona-Server/storage/innobase/trx/trx0trx.cc:2040: case TRX_QUE_ROLLING_BACK:

Here we have:

        /* trx->lock.que_state of an ACTIVE transaction may change
        while we are not holding trx->mutex. We perform a dirty read
        for performance reasons. */

        switch (trx->lock.que_state) {
        case TRX_QUE_RUNNING:
                newline = FALSE; break;
        case TRX_QUE_LOCK_WAIT:
                fputs("LOCK WAIT ", f); break;
        case TRX_QUE_ROLLING_BACK:
                fputs("ROLLING BACK ", f); break;
        case TRX_QUE_COMMITTING:
                fputs("COMMITTING ", f); break;
        default:
                fprintf(f, "que state %lu ", (ulong) trx->lock.que_state);
        }

Percona-Server/storage/innobase/trx/trx0roll.cc:1300: trx->lock.que_state = TRX_QUE_ROLLING_BACK;

Here we have:

/*********************************************************************//**
Starts a rollback operation, creates the UNDO graph that will do the
actual undo operation.
@return query graph thread that will perform the UNDO operations. */
static
que_thr_t*
trx_rollback_start(
/*===============*/
        trx_t* trx, /*!< in: transaction */
        ib_id_t roll_limit) /*!< in: rollback to undo no (for
                                        partial undo), 0 if we are rolling back
                                        the entire transaction */
{

...

        /* Build a 'query' graph which will perform the undo operations */

        roll_graph = trx_roll_graph_build(trx);

        trx->graph = roll_graph;

        trx->lock.que_state = TRX_QUE_ROLLING_BACK;

        return(que_fork_start_command(roll_graph));
 }

So, my idea is that maybe transaction had to do some "mini rollback" to get data for the table at the moment statement execution began, to check some constraint maybe?

Just a speculation for now.