Commit graph

4 commits

Author SHA1 Message Date
unknown
128c3942a8 Bug#17204 "second CALL to procedure crashes Server"
Bug#18282 "INFORMATION_SCHEMA.TABLES provides inconsistent info about invalid views"
This bug caused crashes or resulted in wrong data being returned
when one tried to obtain information from I_S tables about views
using stored functions.

It was caused by the fact that we were using LEX representing
statement which were doing select from I_S tables as active LEX
when contents of I_S table were built. So state of this LEX both
affected and was affected by open_tables() calls which happened
during this process. This resulted in wrong behavior and in
violations of some of invariants which caused crashes.

This fix tries to solve this problem by properly saving/resetting
and restoring part of LEX which affects and is affected by the
process of opening tables and views in get_all_tables() routine.
To simplify things we separated this part of LEX in a new class
and made LEX its descendant.


mysql-test/r/information_schema_db.result:
  test case
mysql-test/t/information_schema_db.test:
  test case
sql/sql_lex.cc:
  To simplify saving/resetting and restoring part of LEX which
  affects and is affected by the process of opening tables and
  views we moved it to new class Query_tables_list and made LEX
  descendant of this class. Also introduced two LEX methods 
  which can be used to save and reset or to restore this state.
sql/sql_lex.h:
  To simplify saving/resetting and restoring part of LEX which
  affects and is affected by the process of opening tables and
  views we moved it to new class Query_tables_list and made LEX
  descendant of this class. Also introduced two LEX methods 
  which can be used to save and reset or to restore this state.
sql/sql_show.cc:
  Now in get_all_tables() routine we properly save/reset and
  restore part of LEX (statement table list and information
  about routines used) which affects and is affected by the
  process of opening tables and views.
sql/sql_table.cc:
  Now we clean-up LEX after opening table (view) in two stages.
  In the first stage we call LEX::cleanup_after_one_table_open()
  to clean-up selects lists and derived tables state. In the
  second stage which happens after close_thread_tables() is
  invoked we call Query_tables_list::reset_query_tables_list(FALSE)
  to rollback changes in Query_tables_list.
2006-05-30 10:45:23 +05:00
unknown
ce39d29493 Fix for bug #18113 "SELECT * FROM information_schema.xxx crashes server"
Crash happened when one selected data from one of INFORMATION_SCHEMA
tables and in order to build its contents server had to open view which
used stored function and table or view on which one had not global or
database-level privileges (e.g. had only table-level or had no
privileges at all).

The crash was caused by usage of check_grant() function, which assumes
that either number of tables to be inspected by it is limited explicitly
or table list used and thd->lex->query_tables_own_last value correspond
to each other (the latter should be either 0 or point to next_global
member of one of elements of this table list), in conditions when
above assumptions were not true. This fix just explicitly limits
number of tables to be inspected. Other negative effects which are
caused by the fact that thd->lex->query_tables_own_last might not
be set properly during processing of I_S tables are less disastrous
and will be reported and fixed separetely.



mysql-test/r/information_schema_db.result:
  Fix for bug #18113 "SELECT * FROM information_schema.xxx crashes server"
    test case
mysql-test/t/information_schema_db.test:
  Fix for bug #18113 "SELECT * FROM information_schema.xxx crashes server"
    test case
sql/sql_acl.cc:
    added note
2006-03-20 13:42:02 +04:00
unknown
f9433acc81 Fix for bug #10659: information_schema_db fail on Mac OS 2005-05-24 14:35:23 +04:00
unknown
bf049c3167 Fix for bug #10018:use INFORMATION_SCHEMA works, but show tables in it returns error 2005-05-06 19:06:10 +00:00