Bug#40281, partitioning the general log table crashes the server

We disallow the partitioning of a log table. You could however
partition a table first, and then point logging to it. This is
not only against the docs, it also crashes the server.

We catch this case now.

mysql-test/r/partition.result:
  results for 40281
mysql-test/t/partition.test:
  test for 40281: show that trying to log to partitioned table fails rather
  to crash the server
sql/ha_partition.cc:
  Signal that we no longer support logging to partitioned tables,
  as per the docs.
sql/sql_partition.cc:
  Some commands like "USE ..." have no select, yet we may try
  to parse partition info after their execution if user set a
  partitioned table as log target. This shouldn't lead to a
  NULL-deref/crash.
This commit is contained in:
Tatiana A. Nurnberg 2009-07-31 14:38:18 +02:00
commit 717d6054f5
4 changed files with 94 additions and 1 deletions

View file

@ -3824,8 +3824,13 @@ bool mysql_unpack_partition(THD *thd,
Item_field objects.
This is not a nice solution since if the parser uses current_select
for anything else it will corrupt the current LEX object.
Also, we need to make sure there even is a select -- if the statement
was a "USE ...", current_select will be NULL, but we may still end up
here if we try to log to a partitioned table. This is currently
unsupported, but should still fail rather than crash!
*/
thd->lex->current_select= old_lex->current_select;
if (!(thd->lex->current_select= old_lex->current_select))
goto end;
/*
All Items created is put into a free list on the THD object. This list
is used to free all Item objects after completing a query. We don't