MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Tatiana Azundris Date:July 25 2009 11:31am
Subject:Re: bzr commit into mysql-5.1-bugteam branch (azundris:2978) Bug#40281
View as plain text  

Hi Davi,

Thanks for looking at this!

Davi Arnaut wrote:
> Hi Tatiana,
> 
> On 7/17/09 2:32 AM, Tatiana A. Nurnberg wrote:
>> #At file:///misc/mysql/forest/40281n/51-40281n/ based on 
>> revid:luis.soares@stripped
>>
>>   2978 Tatiana A. Nurnberg    2009-07-17
>>        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
>>          Don't be so sure there even was an old SELECT.
>>          If there isn't, there's not only no point in going on here,
>>          it will also crash the server.
>>
> 
> Why it crashes? What leads to this problem?

We go down that branch to parse the "PARTITION ..." particle.
To be clear, this happens for the logging; the "PARTITION ..."
bit is the one that we gave when we pointed logging to a new
place; the "PARTITION ..." is *not* part of the *current* statement.
The current statement in this particular case is "USE ...", which
is one of the rare cases where you end up with select==NULL. Since
the PARTITION-parsing is blissfully unaware of this, it will later
try to deref select->something. This why the reporter of the original
bug sees a crash on "USE ..." in their preliminary test case.

My first impulse was to DBUG_ASSERT() against this, but it's a valid
case apparently. This is because the error-handling for logging is
really weird; we do NOT send warnings to the client when they set up
nonsense or logging fails for some other reason. By the time logging
fails, we've already decided on a status and sent it to the client.
Therefore, we only print diagnostics to the *server*. This is not pretty
and strikes me as "less than ideal", but that's the status quo, and it's
definitely intended behavior; comments in the source document this.

Therefore, we just if() out at that point, since there is no value
in trying to fix things further down in the callstack to work for
select==NULL when we don't support the only case where it matters
(logging to partitioned table) anyway.

thanks and regards,
Tatiana
Thread
bzr commit into mysql-5.1-bugteam branch (azundris:2978) Bug#40281Tatiana A. Nurnberg17 Jul
  • Re: bzr commit into mysql-5.1-bugteam branch (azundris:2978) Bug#40281Davi Arnaut24 Jul
    • Re: bzr commit into mysql-5.1-bugteam branch (azundris:2978) Bug#40281Tatiana Azundris25 Jul
      • Re: bzr commit into mysql-5.1-bugteam branch (azundris:2978) Bug#40281Davi Arnaut28 Jul