Bug #70028 P_S threads.INSTRUMENTED not set according to setup_actors
Submitted: 14 Aug 2013 8:08 Modified: 1 Oct 2013 16:39
Reporter: Jesper wisborg Krogh Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Performance Schema Severity:S2 (Serious)
Version:5.6.13 OS:Linux (Oracle Linux 6)
Assigned to: Marc ALFF CPU Architecture:Any

[14 Aug 2013 8:08] Jesper wisborg Krogh
Description:
According to the documentations (https://dev.mysql.com/doc/refman/5.6/en/performance-schema-filtering.html#performance-sche...):

"For foreground threads (resulting from client connections), the initial INSTRUMENTED value is determined by whether the user account associated with the thread matches any row in the setup_actors table. For background threads, INSTRUMENTED is YES by default. setup_actors is not consulted because there is no associated user for background threads."

However if all rows are removed from setup_actors (thus no new foreground threads should be instrumented), new connections are still instrumented. On the other hand, the thread "thread/sql/main" (typical/always THREAD_ID = 1) changes to INSTRUMENTED = NO despite it being a background thread.

How to repeat:
1) Delete all rows in setup_actors:

   DELETE FROM performance_schema.setup_actors;

2) SELECT THREAD_ID, TYPE, INSTRUMENTED FROM threads;

+-----------+------------+--------------+
| THREAD_ID | TYPE       | INSTRUMENTED |
+-----------+------------+--------------+
|         1 | BACKGROUND | YES          |
|         2 | BACKGROUND | YES          |
|         3 | BACKGROUND | YES          |
|         4 | BACKGROUND | YES          |
|         5 | BACKGROUND | YES          |
|         6 | BACKGROUND | YES          |
|         7 | BACKGROUND | YES          |
|         8 | BACKGROUND | YES          |
|         9 | BACKGROUND | YES          |
|        10 | BACKGROUND | YES          |
|        11 | BACKGROUND | YES          |
|        12 | BACKGROUND | YES          |
|        13 | BACKGROUND | YES          |
|        14 | BACKGROUND | YES          |
|        15 | BACKGROUND | YES          |
|        16 | BACKGROUND | YES          |
|        18 | BACKGROUND | YES          |
|        19 | BACKGROUND | YES          |
|        20 | BACKGROUND | YES          |
|        21 | BACKGROUND | YES          |
|        22 | BACKGROUND | YES          |
|        23 | BACKGROUND | YES          |
|        24 | BACKGROUND | YES          |
|        25 | BACKGROUND | YES          |
|        26 | BACKGROUND | YES          |
|        27 | BACKGROUND | YES          |
|        28 | BACKGROUND | YES          |
|        29 | BACKGROUND | YES          |
|        30 | BACKGROUND | YES          |
|        31 | BACKGROUND | YES          |
|        32 | BACKGROUND | YES          |
|        33 | BACKGROUND | YES          |
|        34 | BACKGROUND | YES          |
|        35 | BACKGROUND | YES          |
|        36 | BACKGROUND | YES          |
|        37 | BACKGROUND | YES          |
|        38 | FOREGROUND | YES          |
|        39 | FOREGROUND | YES          |
+-----------+------------+--------------+
38 rows in set (0.00 sec)

3) Create new connection.

4) SELECT THREAD_ID, TYPE, INSTRUMENTED FROM threads;

+-----------+------------+--------------+
| THREAD_ID | TYPE       | INSTRUMENTED |
+-----------+------------+--------------+
|         1 | BACKGROUND | NO           |
|         2 | BACKGROUND | YES          |
|         3 | BACKGROUND | YES          |
|         4 | BACKGROUND | YES          |
|         5 | BACKGROUND | YES          |
|         6 | BACKGROUND | YES          |
|         7 | BACKGROUND | YES          |
|         8 | BACKGROUND | YES          |
|         9 | BACKGROUND | YES          |
|        10 | BACKGROUND | YES          |
|        11 | BACKGROUND | YES          |
|        12 | BACKGROUND | YES          |
|        13 | BACKGROUND | YES          |
|        14 | BACKGROUND | YES          |
|        15 | BACKGROUND | YES          |
|        16 | BACKGROUND | YES          |
|        18 | BACKGROUND | YES          |
|        19 | BACKGROUND | YES          |
|        20 | BACKGROUND | YES          |
|        21 | BACKGROUND | YES          |
|        22 | BACKGROUND | YES          |
|        23 | BACKGROUND | YES          |
|        24 | BACKGROUND | YES          |
|        25 | BACKGROUND | YES          |
|        26 | BACKGROUND | YES          |
|        27 | BACKGROUND | YES          |
|        28 | BACKGROUND | YES          |
|        29 | BACKGROUND | YES          |
|        30 | BACKGROUND | YES          |
|        31 | BACKGROUND | YES          |
|        32 | BACKGROUND | YES          |
|        33 | BACKGROUND | YES          |
|        34 | BACKGROUND | YES          |
|        35 | BACKGROUND | YES          |
|        36 | BACKGROUND | YES          |
|        37 | BACKGROUND | YES          |
|        38 | FOREGROUND | YES          |
|        39 | FOREGROUND | YES          |
|        46 | FOREGROUND | YES          |
+-----------+------------+--------------+
39 rows in set (0.00 sec)

Suggested fix:
N/A
[1 Oct 2013 16:39] Paul DuBois
Noted in 5.6.15, 5.7.3 changelogs.

With the thread pool plugin enabled, the the PROCESSLIST_USER and
PROCESSLIST_HOST columns of the Performance Schema threads table were
always NULL for client sessions. Also, for the main thread, those
columns were not NULL but set to a user account.

Note:
As part of the bug fix implementation, Performance Schema
instrumentation for the thread pool plugin was changed to use
thread_pool, not sql.