Commit graph

20 commits

Author SHA1 Message Date
Sergei Petrunia
eebe2090c8 Merge 10.3 -> 10.4 2021-06-30 18:41:46 +03:00
Oleksandr Byelkin
c07325f932 Merge branch '10.3' into 10.4 2019-05-19 20:55:37 +02:00
Marko Mäkelä
be85d3e61b Merge 10.2 into 10.3 2019-05-14 17:18:46 +03:00
Marko Mäkelä
26a14ee130 Merge 10.1 into 10.2 2019-05-13 17:54:04 +03:00
Vicențiu Ciorbaru
cb248f8806 Merge branch '5.5' into 10.1 2019-05-11 22:19:05 +03:00
Vicențiu Ciorbaru
5543b75550 Update FSF Address
* Update wrong zip-code
2019-05-11 21:29:06 +03:00
Oleksandr Byelkin
6c306a729d Cleanup of derived table interface 2019-04-16 08:57:24 +02:00
Eugene Kosov
a97ca9fe5b remove dead code 2019-03-22 22:31:26 +04:00
Marko Mäkelä
9835f7b80f Merge 10.1 into 10.2 2019-03-04 16:46:58 +02:00
Oleksandr Byelkin
7b5c63856b Merge branch '5.5' into 10.0 2019-02-28 21:50:00 +01:00
Alexander Barkov
0ad598a00b A cleanup in derived table handling: removing duplicate code from st_select_lex::handle_derived()
st_select_lex::handle_derived() and mysql_handle_list_of_derived() had
exactly the same implementations.

- Adding a new method LEX::handle_list_of_derived() instead
- Removing public function mysql_handle_list_of_derived()
- Reusing LEX::handle_list_of_derived() in st_select_lex::handle_derived()
2019-02-28 18:13:28 +04:00
Igor Babaev
7a29ca2776 Fixed the bug mdev-12563.
The bug happened when the specification of a recursive CTE had
no recursive references at the top level of the specification.
In this case the regular processing of derived table references
of the select containing a non-recursive reference to this
recursive CTE misses handling the specification unit.
At the preparation stage any non-recursive reference to a
recursive CTE must be handled after the preparation of the
specification unit for this CTE. So we have to force this
preparation when regular handling of derived tables does not
do it.
2017-04-28 21:59:11 -07:00
Galina Shalygina
eb2c147475 The consolidated patch for mdev-9197. 2016-08-23 00:39:12 +03:00
Michael Widenius
b83f692565 MDEV-6668: Server crashes in check_view_single_update on concurrent DDL/DML flow with views and triggers
Call mysql_derived_reinit() if we are reusing view.
This is needed as during a previous error condition the view may not have been reset

sql/sql_derived.cc:
  More DBUG_PRINT
  Always reset merged_for_insert (no reason to not do that)
sql/sql_derived.h:
  Added prototype
sql/sql_insert.cc:
  More DBUG_PRINT
  Added DBUG_ASSERT
sql/sql_view.cc:
  Call mysql_derived_reinit() if we are reusing view.
  This is needed as during a previous error condition the view may not have been reset
sql/table.cc:
  More DBUG_PRINT
2015-01-29 15:12:32 +02:00
Sergei Golubchik
0e007344ea mysql-5.5.18 merge 2011-11-03 19:17:05 +01:00
Sergei Golubchik
76f0b94bb0 merge with 5.3
sql/sql_insert.cc:
  CREATE ... IF NOT EXISTS may do nothing, but
  it is still not a failure. don't forget to my_ok it.
  ******
  CREATE ... IF NOT EXISTS may do nothing, but
  it is still not a failure. don't forget to my_ok it.
sql/sql_table.cc:
  small cleanup
  ******
  small cleanup
2011-10-19 21:45:18 +02:00
Kent Boortz
02e07e3b51 Updated/added copyright headers 2011-06-30 17:46:53 +02:00
Jon Olav Hauglid
8b1571d803 Bug #58730 Assertion failed: table->key_read == 0 in close_thread_table,
temptable views

The TABLE::key_read field indicates if the optimizer has found that row
retrieval only should access the index tree. The triggered assert
inside close_thread_table() checks that this field has been reset when
the table is about to be closed.

During normal execution, these fields are reset right before tables are
closed at the end of mysql_execute_command(). But in the case of errors,
tables are closed earlier. The patch for Bug#52044 refactored the open
tables code so that close_thread_tables() is called immediately if
opening of tables fails. At this point in the execution, it could
happend that all TABLE::key_read fields had not been properly reset,
therefore triggering the assert.

The problematic statement in this case was EXPLAIN where the query
accessed two derived tables and where the first derived table was
processed successfully while the second derived table was not.
Since it was an EXPLAIN, TABLE::key_read fields were not reset after
successful derived table processing since the state needs to be 
accessible afterwards. When processing of the second derived table
failed, it's corresponding SELECT_LEX_UNIT was cleaned, which caused
it's TABLE::key_read fields to be reset. Since processing failed,
the error path of open_and_lock_tables() was entered and
close_thread_tables() was called. The assert was then triggered due
to the TABLE::key_read fields set during processing of the first
derived table.

This patch fixes the problem by adding a new derived table processor,
mysql_derived_cleanup() that is called after mysql_derived_filling().
It causes cleanup of all SELECT_LEX_UNITs to be called, resetting
all relevant TABLE::key_read fields.

Test case added to derived.test.
2010-12-16 10:55:23 +01:00
Alexander Nozdrin
60333fbec9 A post-fix patch for WL#4877/WL#5030:
Fix tons of warnings about mismatch struct and class usage.
2010-04-12 17:17:37 +04:00
Mats Kindahl
23d8586dbf WL#5030: Split and remove mysql_priv.h
This patch:

- Moves all definitions from the mysql_priv.h file into
  header files for the component where the variable is
  defined
- Creates header files if the component lacks one
- Eliminates all include directives from mysql_priv.h
- Eliminates all circular include cycles
- Rename time.cc to sql_time.cc
- Rename mysql_priv.h to sql_priv.h
2010-03-31 16:05:33 +02:00