MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Davi Arnaut Date:July 27 2009 11:40pm
Subject:Re: bzr commit into mysql-5.1-bugteam branch (azundris:2978) Bug#40281
View as plain text  
On 7/25/09 8:31 AM, Tatiana Azundris wrote:
> 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/
>>> Signal that we no longer support logging to partitioned tables,
>>> as per the docs.
>>> @ sql/
>>> 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.

OK. Approved, but please add a comment that there might be attempts to 
open a partitioned table under a command (or statement) which might not 
have a associated SELECT structure.
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