Although the query cache doesn't support retrieval of statements containing
column level access control, it was still possible to cache such statements
thus wasting memory.
This patch extends the access control check on the target tables to avoid
caching a statement with column level restrictions.
Views are excepted and can be cached but only retrieved by super user account.
Although the query cache doesn't support retrieval of statements containing
column level access control, it was still possible to cache such statements
thus wasting memory.
This patch extends the access control check on the target tables to avoid
caching a statement with column level restrictions.
The subst_spvars function is used to create query string with SP variables
substituted with their values. This string is used later for the binary log
and for the query cache. The problem is that the
query_cache_send_result_to_client function requires some additional space
after the query to store database name and query cache flags. This
space wasn't reserved by the subst_spvars function which led to a memory
corruption and crash.
Now the subst_spvars function reserves additional space for the query cache.
A race condition in the integration between MyISAM and the query cache code
caused the query cache to fail to invalidate itself on concurrently inserted
data.
This patch fix this problem by using the existing handler interface which, upon
each statement cache attempt, compare the size of the table as viewed from the
cache writing thread and with any snap shot of the global table state. If the
two sizes are different the global table size is unknown and the current
statement can't be cached.
Changed code to enforce that SQL_CACHE only in the first SELECT is used to turn on caching(as documented), but any SQL_NO_CACHE will turn off caching (not documented, but a useful behaviour, especially for machine generated queries). Added test cases to explicitly test the documented caching behaviour and test cases for the reported bug.
When all table blocks were removed from the query cache the client session
hung in a tight loop waiting on an impossible condition while consuming a lot
of CPU.
This patch also corrects an error which caused valid tables to sometimes be
removed from the query cache.
Cache".
WL#1569 "Prepared Statements: implement support of Query Cache".
Prepared SELECTs did not look up in the query cache, and their results
were not stored in the query cache. This made them slower than
non-prepared SELECTs in some cases.
The fix is to re-use the expanded query (the prepared query where
"?" placeholders are replaced by their values, at execution time)
for searching/storing in the query cache.
It works fine for statements prepared via mysql_stmt_prepare(), which
are the most commonly used and were the scope of this bugfix and WL.
It works less fine for statements prepared via the SQL command
PREPARE...FROM, which are still not using the query cache if they
have at least one parameter (because then the expanded query contains
names of user variables, and user variables don't work with the
query cache, even in non-prepared queries).
Note that results from prepared SELECTs, which are in the binary
protocol, and results from normal SELECTs, which are in the text
protocol, ignore each other in the query cache, because a result in the
binary protocol should never be served to a SELECT expecting the text
protocol and vice-versa.
Note, after this patch, bug 25843 starts applying to query cache
("changing default database between PREPARE and EXECUTE of statement
breaks binlog"), we need to fix it.
- Implement --secure-file-priv=<dir> option that limits
"load_file", "LOAD DATA" and "SELECT .. INTO OUTFILE" to work
with files in specified dir.
- Use above option for mysqld in mysql-test-run.pl
The regression is caused by the fix for bug 14767. When INSERT ... SELECT
used a view in the SELECT list that was not inlined, and there was an
active transaction, the server could crash in Query_cache::invalidate.
On INSERT ... SELECT only the table being inserted into is invalidated.
Thus views that can't be inlined are skipped from invalidation.
The bug manifests itself in two ways so there is 2 test cases.
One checks that the only the table being inserted into is invalidated.
And the second one checks that there is no crash on INSERT ... SELECT.
SHOW STATUS are not anymore put in slow query log because of no index usage.
Implemntation done by removing orig_sql_command and moving logic of SHOW STATUS to mysql_excute_command()
This simplifies code and allows us to remove some if statements all over the code.
Upgraded uc_update_queries[] to sql_command_flags and added more bitmaps to better categorize commands.
This allowed some overall simplifaction when testing sql_command.
Fixes bugs:
Bug#10210: running SHOW STATUS increments counters it shouldn't
Bug#19764: SHOW commands end up in the slow log as table scans
