MySQL Bugs: #53617: Missing performance schema tables not reported in the server log at startup

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

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.

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.

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.

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

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.

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.

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.

Patch approved.

Pushed into:
- mysql-next-mr-bugfixing
- mysql-6.0-codebase-bugfixing

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)

Pushed into mysql-next-mr (revid:alik@sun.com-20100520100140-5bzrtadw4w419i3m) (version source revid:alik@sun.com-20100520100049-1njm09rkvnhmysnr) (pib:16)

Noted in 6.0.14 changelog.

Missing Performance Schema tables were not reported in the error log
at server startup.

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

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)

Pushed into mysql-trunk-bugfixing (5.5.6)

Noted in 5.5.6 changelog.

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)

Pushed into mysql-next-mr (revid:alik@sun.com-20100723121929-90e9zemk3jkr2ocy) (version source revid:vasil.dimov@oracle.com-20100531152341-x2d4hma644icamh1) (pib:18)

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)

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)

Bug is not present in any released 5.6.x version.