Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-10407

Transactions not in Galera's receive queue when FLUSH TABLES WITH READ LOCK executed

    XMLWordPrintable

Details

    Description

      Let's say that we have a 2 node cluster.

      On one of the nodes, let's set up a table like the following:

      CREATE TABLE db1.lock_test (
      	id int auto_increment primary key,
      	str varchar(50)
      );
      

      Then on node 2, execute the following:

      FLUSH TABLES WITH READ LOCK;
      

      Then on node 1, execute the following:

      INSERT INTO db1.lock_test VALUES (1, 'str1');
      

      And then let's look at the state on node 2:

      MariaDB [(none)]> SELECT * FROM db1.lock_test;
      Empty set (0.00 sec)
       
      MariaDB [(none)]> SHOW GLOBAL STATUS WHERE Variable_name IN ('wsrep_local_state_comment', 'wsrep_local_recv_queue', 'wsrep_local_recv_queue_max', 'wsrep_flow_control_paused', 'wsrep_flow_control_sent', 'wsrep_flow_control_recv');
      +----------------------------+----------+
      | Variable_name              | Value    |
      +----------------------------+----------+
      | wsrep_local_recv_queue     | 0        |
      | wsrep_local_recv_queue_max | 1        |
      | wsrep_flow_control_paused  | 0.000000 |
      | wsrep_flow_control_sent    | 0        |
      | wsrep_flow_control_recv    | 0        |
      | wsrep_local_state_comment  | Synced   |
      +----------------------------+----------+
      6 rows in set (0.00 sec)
      

      The new row is not in the table on node 2 and it is not in node 2's receive queue, since wsrep_local_recv_queue = 0.

      However, let's do the following on node 2:

      UNLOCK TABLES;
      

      The row does correctly show up at that point:

      MariaDB [(none)]> SELECT * FROM db1.lock_test;
      +----+------+
      | id | str  |
      +----+------+
      |  1 | str1 |
      +----+------+
      1 row in set (0.00 sec)
       
      MariaDB [(none)]> SHOW GLOBAL STATUS WHERE Variable_name IN ('wsrep_local_state_comment', 'wsrep_local_recv_queue', 'wsrep_local_recv_queue_max', 'wsrep_flow_control_paused', 'wsrep_flow_control_sent', 'wsrep_flow_control_recv');
      +----------------------------+----------+
      | Variable_name              | Value    |
      +----------------------------+----------+
      | wsrep_local_recv_queue     | 0        |
      | wsrep_local_recv_queue_max | 1        |
      | wsrep_flow_control_paused  | 0.000000 |
      | wsrep_flow_control_sent    | 0        |
      | wsrep_flow_control_recv    | 0        |
      | wsrep_local_state_comment  | Synced   |
      +----------------------------+----------+
      6 rows in set (0.00 sec)
      

      Is it intentional that pending transactions aren't in the receive queue when a lock is held by FLUSH TABLES WITH READ LOCK?

      Attachments

        Activity

          People

            jplindst Jan Lindström (Inactive)
            GeoffMontee Geoff Montee (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.