List:Commits« Previous MessageNext Message »
From:Davi Arnaut Date:March 2 2011 10:00pm
Subject:Re: bzr commit into mysql-trunk branch (jon.hauglid:3717) Bug#11766752
View as plain text  
Hi Jon,

On 3/2/11 8:49 AM, Jon Olav Hauglid wrote:
> #At file:///export/home/x/mysql-trunk-bug59936/ based on
> revid:vinay.fisrekar@stripped
>
>   3717 Jon Olav Hauglid	2011-03-02
>        Bug #11766752 (former 59936)
>        Multiple XA assertions - transactional statement fuzzer
>
>        The problem was that the server for several statements did not check
>        the state of the current XA transaction (if any) before trying to
>        execute the statement. Specifically, you are not supposed to do
>        anything other than XA PREPARE / XA COMMIT ONE PHASE when in IDLE state,
>        or anything other than XA COMMIT / XA ROLLBACK in PREPARED state.
>
>        The assertions triggered by the testcase posted in the bug report,
>        was triggered by trying to access a table or rollback to a savepoint
>        when the current XA transaction was in PREPARED state.
>
>        This patch fixes the problem by reporting ER_XAER_RMFAIL error if
>        1) A statement tries to start a statement transaction when XA state
>           is IDLE or PREPARED.
>        2) SAVEPOINT or ROLLBACK TO SAVEPOINT is executed with an active
>           XA transaction. (Similar to what is already done for COMMIT/ROLLBACK)
>
>        Test case added to xa.test.
>        Also verified with the C testcase posted on the bug report.
>

[...]

>
> === modified file 'sql/handler.cc'
> --- a/sql/handler.cc	2011-03-01 14:47:01 +0000
> +++ b/sql/handler.cc	2011-03-02 11:49:45 +0000
> @@ -975,6 +975,13 @@ void trans_register_ha(THD *thd, bool al
>     DBUG_ENTER("trans_register_ha");
>     DBUG_PRINT("enter",("%s", all ? "all" : "stmt"));
>
> +  enum xa_states xa_state= thd->transaction.xid_state.xa_state;
> +  if (xa_state == XA_IDLE || xa_state == XA_PREPARED)
> +  {
> +    my_error(ER_XAER_RMFAIL, MYF(0), xa_state_names[xa_state]);
> +    DBUG_VOID_RETURN;
> +  }

I'm not sure I understand how this is supposed to work. It seems that 
currently this function cannot fail, thus a engine will continue 
processing the transaction as usual. Won't we still have trouble 
depending on what the engine does?

Regards,

Davi
Thread
bzr commit into mysql-trunk branch (jon.hauglid:3717) Bug#11766752Jon Olav Hauglid2 Mar
  • Re: bzr commit into mysql-trunk branch (jon.hauglid:3717) Bug#11766752Davi Arnaut2 Mar