Bug #53617 Missing performance schema tables not reported in the server log at startup
Submitted: 13 May 2010 8:15 Modified: 4 Aug 2010 20:08
Reporter: Mikiya Okuno Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server: Performance Schema Severity:S3 (Non-critical)
Version:5.5.3-m3, 5.5.4-m3 OS:Any
Assigned to: Marc Alff CPU Architecture:Any
Triage: Triaged: D3 (Medium)

[13 May 2010 8:15] Mikiya Okuno
Description:
SHOW VARIABLES says performance_schema is ON even if the performance_schema database is not present. (Schema is dropped online or deleted when offline.)

I'm not certain if this is a bug. As P_S is a storage engine, so it will not aware of existence of performance_schema database. Users should maintain the database properly.

However, IMHO, at least some error messages should be reported in the error log. Currently, even if P_S is enabled and the database is absent, no errors are reported and the only message like "Buffered information: Performance schema enabled." appears. Instead, some errors should be reported.

How to repeat:
DROP P_S database.
Restart the server with --performance_schema option.
No errors are reported and P_S isn't disabled.

Suggested fix:
Error should be reported or something like that.
[13 May 2010 8:18] Giuseppe Maxia
Additionally, when you restart a server after deleting the P_S database, the error log says: 
"[Note] Buffered information: Performance schema enabled."
At the very minimum, it should issue a warning or an error.
[13 May 2010 9:18] Marc Alff
The variable "performance_schema" "ON" indicates that the performance schema instrumentation is initialized, and that the performance schema is collecting data from the server / storage engines.

The performance schema tables are used to expose the data collected.

Even when the SQL tables themselves are damaged, for example after:
DROP DATABASE perfschema;
the instrumentation itself is not affected and continue to operate.

So, in a degraded operating mode where the tables got removed,
starting a server with --performance_schema will collect data,
and the message in the log announcing that data is collected is correct.

Now, in this operating mode, when a
SELECT * from performance_schema.EVENTS_WAITS_CURRENT
is attempted, this statement will fail as expected, because the table itself is not present.

In short, the performance schema *is* on, but it's just that data can not be read from it.

This works as designed and as expected.

Closing as not a bug.
[13 May 2010 9:29] Giuseppe Maxia
Marc,
It may work as expected from the developers standpoint, but not from the user's.
The documentation talks about performance schema tables. Users surely expect to be informed if such tables are not there.
So, if it has been designed this way, it was a mistake, IMO. Hence, it's a bug
[13 May 2010 9:31] Marc Alff
Clarifications

When the performance schema is initialized, it also checks for the integrity of every table. Errors are printed in the server log when a table is missing or has not the proper structure.

However, a bug did prevent this message to be printed in the log:
the fix for
Bug#46792 Hard coded 'mysql' table schema in error messages
is required to actually see the error message

Any error related to a given table is not fatal: using the non damaged tables is still operational. This is why the initialization continues, as designed, for robustness.

The extreme case when *every* table is damaged, for example with DROP DATABASE performance_schema, is not treated separately.
[13 May 2010 10:22] Marc Alff
Clarifications, continued.

The original bug report title was:
  SHOW VARIABLES says P_S is on even if the schema doesn't exist
That itself is not a bug.

Also, the report asked to print error messages in the server log, at startup.

When a performance schema table has not the expected structure,
this is already implemented.
See the test case tampered_perfschema_table1.test

When a performance schema table does not exist, the server is supposed
to also print an error message, but does not.
This is a verified bug.

Changing the report title and status to fix this case.

The problem is in PFS_engine_table_share::check_one_table(),
no error message is printed when open and lock table fails.
[13 May 2010 14:25] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/108249

3176 Marc Alff	2010-05-13
      Bug#53617 Missing performance schema tables not reported in the server log at startup
      
      Before this fix, when the performance schema tables are missing due to a broken
      installation or upgrade, the server would start but not report missing performance schema tables.
      
      With this fix, missing tables are reported in the server error log, like for example as:
      ERROR Native table 'performance_schema'.'SETUP_TIMERS' has the wrong structure
      
      This test can not be automated: tested manually, no script provided.
[17 May 2010 17:00] Christopher Powers
Patch approved.
[18 May 2010 7:16] Marc Alff
Pushed into:
- mysql-next-mr-bugfixing
- mysql-6.0-codebase-bugfixing
[20 May 2010 10:03] Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20100520100225-oe4iuu5kuzsx0knq) (version source revid:alik@sun.com-20100520100057-rmn5y3o3ij726bm7) (merge vers: 6.0.14-alpha) (pib:16)
[20 May 2010 10:06] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100520100140-5bzrtadw4w419i3m) (version source revid:alik@sun.com-20100520100049-1njm09rkvnhmysnr) (pib:16)
[20 May 2010 15:16] Paul Dubois
Noted in 6.0.14 changelog.

Missing Performance Schema tables were not reported in the error log
at server startup.
[16 Jul 2010 0:06] Marc Alff
Changing to need merge for 5.5

The fix is extremely simple (no risk or effort),
and this will greatly improve the user experience for install/upgrades,
so there is no good reason to not put the fix in mysql-trunk
[16 Jul 2010 0:19] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/113718

3118 Marc Alff	2010-07-15
      Bug#53617 Missing performance schema tables not reported in the server log at startup
      
      Backport from mysql-next-mr (5.6) to mysql-trunk (5.5)
[16 Jul 2010 0:31] Marc Alff
Pushed into mysql-trunk-bugfixing (5.5.6)
[22 Jul 2010 16:14] Paul Dubois
Noted in 5.5.6 changelog.
[23 Jul 2010 12:26] Bugs System
Pushed into mysql-trunk 5.5.6-m3 (revid:alik@sun.com-20100723121820-jryu2fuw3pc53q9w) (version source revid:vasil.dimov@oracle.com-20100531152341-x2d4hma644icamh1) (merge vers: 5.5.5-m3) (pib:18)
[23 Jul 2010 12:33] Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100723121929-90e9zemk3jkr2ocy) (version source revid:vasil.dimov@oracle.com-20100531152341-x2d4hma644icamh1) (pib:18)
[4 Aug 2010 8:10] Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100520123900-5kadc9fvcxz30s75) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:25] Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:alik@sun.com-20100520123900-5kadc9fvcxz30s75) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 20:08] Paul Dubois
Bug is not present in any released 5.6.x version.