Comment 1 for bug 1269085

Tested with:

=== modified file 'Percona-Server/sql/lock.cc'
--- Percona-Server/sql/lock.cc 2013-02-12 21:54:12 +0000
+++ Percona-Server/sql/lock.cc 2014-01-15 11:04:10 +0000
@@ -1058,6 +1058,8 @@
     If we didn't succeed lock_global_read_lock(), or if we already suceeded
     make_global_read_lock_block_commit(), do nothing.
   */
+ if (m_state != GRL_ACQUIRED)
+ DBUG_RETURN(0);

 #ifdef WITH_WSREP
   if (m_mdl_blocks_commits_lock)
@@ -1072,8 +1074,6 @@
   }
 #endif /* WITH_WSREP */

- if (m_state != GRL_ACQUIRED)
- DBUG_RETURN(0);

   mdl_request.init(MDL_key::COMMIT, "", "", MDL_SHARED, MDL_EXPLICIT);

Works as vanilla mysql now:

MySQL [test]> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)

MySQL [test]> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)

MySQL [test]> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)

MySQL [test]> flush tables with read lock;
Query OK, 0 rows affected (0.00 sec)

It doesn't try to resume and then pause for every FTWRL on same
connection.

Note that this affects FTWRL issued only on same connection and
not other connections (for which it says - "[Warning] WSREP:
Attempt to lock an already locked monitor.").

For the same connection, a lock_global_read_lock after FTWRL is a
no-op, so this makes FTWRL issued on same connection a no-op
after the first one.

The

#ifdef WITH_WSREP
  if (m_mdl_blocks_commits_lock)
  {
    WSREP_DEBUG("GRL was in block commit mode when entering "
  "make_global_read_lock_block_commit");
    thd->mdl_context.release_lock(m_mdl_blocks_commits_lock);
    m_mdl_blocks_commits_lock= NULL;
    wsrep_locked_seqno= WSREP_SEQNO_UNDEFINED;
    wsrep->resume(wsrep);
    m_state= GRL_ACQUIRED;
  }
#endif /* WITH_WSREP */

fragment was added for https://bugs.launchpad.net/codership-mysql/+bug/847353