MySQL Bugs: #35039: Falcon INFORMATION_SCHEMA memory tables are empty for non-debug builds.

Bug #35039	Falcon INFORMATION_SCHEMA memory tables are empty for non-debug builds.
Submitted:	4 Mar 2008 15:53	Modified:	2 May 2008 1:27
Reporter:	Kevin Lewis	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0.4	OS:	Any
Assigned to:	Vladislav Vaintroub	CPU Architecture:	Any

Description:
These INFORMATION_SCHEMA tables;
FALCON_RECORD_CACHE_SUMMARY
FALCON_SYSTEM_MEMORY_DETAIL
FALCON_RECORD_CACHE_DETAIL
FALCON_SYSTEM_MEMORY_SUMMARY

only work in non-debug builds because the file name and line number of each memory allocation is typically identified like this.

#ifdef _DEBUG
#undef THIS_FILE
static const char THIS_FILE[]=__FILE__;
#endif

Robin Schumacher wrote;
The stats appear valuable to have, so I'd like to have them available in standard builds unless you guys think the data really isn't of much use for tuning/diagnostic purposes.

How to repeat:
Using a non debug build;
mysql> select * from falcon_record_cache_summary;
Empty set (0.00 sec)

mysql> select * from falcon_system_memory_summary;
Empty set (0.01 sec)

Suggested fix:
We could remove the #ifdef _DEBUG or replace it with something that is typically compiled in both builds, but that can be turned off if necessary.

Jim Starkey wrote;
I don't object to making the memory detail and summary tables visible 
for non-debug builds, but I have a huge problem with populating them.  
To track memory details, we need to track the module name and line 
number in the memory header.  Exclusive of the code to pass and 
initialize these fields, the additional header fields add 16 bytes to 
every allocated object in Falcon.  Since out biggest exposure is memory 
usage, this is shooting ourselves in the foot.

We could rewrite the memory summary table to compute statistics directly 
rather than summarizing detail data, but I'm not sure it's worth it, 
frankly.

>Robin Schumacher wrote:
> If it's a performance drag to do this, then don't.  
>We'll just doc the fact that they aren't available 
>in non-debug builds. 

Jim Starkey wrote;
It's absolutely a performance drag

>Robin Schumacher wrote:
>Then for the time being, let's not enable any of the 
>Falcon memory tables for anything other than non-debug 
>builds and doc that fact. 

Kevin Lewis is reassigning this bug to Vlad so that he can disable the display Falcon memory tables in release builds.  In other words, when you do this;
   USE INFORMATION_SCHEMA;
   SHOW TABLES;
The four Falcon memory usage tables should not show up.

Note that if the previous suggestion is implemented, then debug and non-debug builds will return different results for falcon_options.test.  They will report different sets of information schema tables.

Hakan, can we change the tests so that these tables are not queried? Or is there a better solution?

Thank you for the bug report.

>Robin Schumacher wrote:
>From a tech standpoint, I can't help, but I can say that 
>Oracle has various performance diagnostic objects that 
>aren't enabled under standard operating procedures, but 
>can be via special parms and such.  And all of that is
>spelled out in their docs.  The views report no data if 
>the parms aren't set, and collect/report data if enabled 
>by the DBA.  Just a thought. 

Jim Starkey wrote;
No disagreement.  But if we can't pass our test suite due 
to limitations of our test system, we're between a rock 
and a hard place.

I think the best compromise is to have all information schema 
tables present under all conditions but populated only in 
debugging builds.  Perfect?  No.

After much discussion, the Falcon team has determined that allowing these INFORMATION_SCHEMA tables to be visible for all builds, but only return data for debug builds is the best approach.  Our opinion is that it is easier for a customer to get no data from a query than to get a 'table does not exist' error.

Please document that the above mentioned falcon memory tables return no data unless it is a debug build.

Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.