Manual does not describe Innodb_current_row_locks in any useful way

Bug #1408971 reported by Valerii Kravchuk
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.1
Won't Fix
Medium
Unassigned
5.5
Triaged
Medium
Borys Belinsky
5.6
Triaged
Medium
Borys Belinsky
5.7
Triaged
Medium
Borys Belinsky

Bug Description

Manual page about extended SHOW ENGINE INNODB STATUS in Percona Server 5.6 (http://www.percona.com/doc/percona-server/5.6/diagnostics/innodb_show_status.html#transactions) is very brief while describing new status variables and their correspondence to sections of the InnoDB status output. Check this example (TRANSACTION section specifically):

...
------------
TRANSACTIONS
------------
Trx id counter 76600
Purge done for trx's n:o < 76600 undo n:o < 0 state: running but idle
History list length 586
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 76596, not started
MySQL thread id 39, OS thread handle 0x7fef74317700, query id 159 localhost root cleaning up
---TRANSACTION 76595, not started
MySQL thread id 38, OS thread handle 0x7fef74358700, query id 161 localhost root init
show engine innodb status
---TRANSACTION 76597, ACTIVE 106 sec
4 lock struct(s), heap size 1184, 7 row lock(s), undo log entries 6
MySQL thread id 40, OS thread handle 0x7fef742d6700, query id 153 localhost root cleaning up
TABLE LOCK table `test`.`t3` trx id 76597 lock mode IX
RECORD LOCKS space id 1416 page no 3 n bits 72 index `PRIMARY` of table `test`.`t3` trx id 76597 lock_mode X
RECORD LOCKS space id 1416 page no 3 n bits 72 index `PRIMARY` of table `test`.`t3` trx id 76597 lock_mode X
RECORD LOCKS space id 1416 page no 3 n bits 72 index `PRIMARY` of table `test`.`t3` trx id 76597 lock_mode X locks rec but not gap
----------------------------
END OF INNODB MONITOR OUTPUT
============================

1 row in set (0,00 sec)

mysql> show global status like 'Innodb_current_row%';
+--------------------------+-------+
| Variable_name | Value |
+--------------------------+-------+
| Innodb_current_row_locks | 3 |
+--------------------------+-------+
1 row in set (0,00 sec)

Now, tell my by the manual (or from any other source) what the value of Innodb_current_row_locks shows in this case and how it is related to anything about row locks? Is it a count of RECORD LOCKS above, something else?

Tags: doc
Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :

Please, make sure to provide example of transactions section that will allow to show and explain values of all status variables mentioned at http://www.percona.com/doc/percona-server/5.6/diagnostics/innodb_show_status.html#transactions

tags: added: doc
information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Valerii Kravchuk (valerii-kravchuk) wrote :
Download full text (5.2 KiB)

I've spent some time checking the code to find out what this variable really shows:

[openxs@centos ~]$ cd git/percona-server/
[openxs@centos percona-server]$ grep -rni Innodb_current_row_locks *
doc/source/ps-variables.rst:788: * - :variable:`Innodb_current_row_locks`
doc/source/diagnostics/innodb_show_status.rst:432:.. variable:: Innodb_current_row_locks
storage/innobase/include/srv0srv.h:1047: ulint innodb_current_row_locks;
storage/innobase/srv/srv0srv.cc:1763: export_vars.innodb_current_row_locks
storage/innobase/handler/ha_innodb.cc:809: (char*) &export_vars.innodb_current_row_locks, SHOW_LONG},

So, the only place where it's referred in the code (5.6.27 from GitHub) is in srv0srv.cc:

/******************************************************************//**
Function to pass InnoDB status variables to MySQL */
UNIV_INTERN
void
srv_export_innodb_status(void)
/*==========================*/
{
...
        export_vars.innodb_current_row_locks
                = lock_sys->rec_num;
...

First, let's check when srv_export_innodb_status() is called:

[openxs@centos percona-server]$ grep -rn srv_export_innodb_status *
storage/innobase/include/srv0srv.h:812:srv_export_innodb_status(void);
storage/innobase/srv/srv0mon.cc:1435:srv_export_innodb_status() for related global counters used by
storage/innobase/srv/srv0srv.cc:1577:srv_export_innodb_status(void)
storage/innobase/handler/ha_innodb.cc:13330: srv_export_innodb_status();
[openxs@centos percona-server]$

So, this is where it's called:

/************************************************************************//**
Here we export InnoDB status variables to MySQL. */
static
void
innodb_export_status()
/*==================*/
{
        if (innodb_inited) {
                srv_export_innodb_status();
        }
}

Let's check when innodb_export_status() is called:

[openxs@centos percona-server]$ vi +13330 storage/innobase/handler/ha_innodb.cc
[openxs@centos percona-server]$ grep -rn innodb_export_status *
storage/innobase/handler/ha_innodb.cc:13326:innodb_export_status()
storage/innobase/handler/ha_innodb.cc:16429: innodb_export_status();
[openxs@centos percona-server]$

So, here it is:

/****************************************************************//**
Callback function for accessing the InnoDB variables from MySQL:
SHOW VARIABLES. */
static
int
show_innodb_vars(
/*=============*/
        THD* thd,
        SHOW_VAR* var,
        char* buff)
{
        innodb_export_status();
        var->type = SHOW_ARRAY;
        var->value = (char*) &innodb_status_variables;

        return(0);
}

So, we can assume it's called every time when SHOW VARIABLES is called. Now, let's check where lock_sys->rec_num comes from:

[openxs@centos percona-server]$ grep -rn 'lock_sys->rec_num' *
...
storage/innobase/lock/lock0lock.cc:619: lock_sys->rec_num = 0;
storage/innobase/lock/lock0lock.cc:1869: lock_sys->rec_num++;
storage/innobase/lock/lock0lock.cc:2511: lock_sys->rec_num--;
storage/innobase/lock/lock0lock.cc:2562: lock_sys->rec_num--;
storage/innobase/srv/srv0srv.cc:1764: = lock_sys->rec_num;

Creates a new record lock and...

Read more...

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1599

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.