List:Commits« Previous MessageNext Message »
From:Guilhem Bichot Date:January 19 2011 8:14pm
Subject:Re: bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260)
View as plain text  
Hello,

Davi Arnaut a écrit, Le 19.01.2011 20:08:
> On 1/19/11 4:58 PM, Guilhem Bichot wrote:
>> #At 
>> file:///home/mysql_src/bzrrepos_new/mysql-next-mr-opt-backporting-wl4800/ 
>> based on revid:guilhem.bichot@stripped
>>
>>   3260 Guilhem Bichot    2011-01-19
>>        todo question
>>
>>      modified:
>>        WL4800_TODO.txt
>> === modified file 'WL4800_TODO.txt'
>> --- a/WL4800_TODO.txt    2011-01-17 20:41:34 +0000
>> +++ b/WL4800_TODO.txt    2011-01-19 18:58:53 +0000
>> @@ -44,3 +44,7 @@ Make --opt-trace-protocol dump traces to
>>   can run with it without failing all tests.
>>
>>   Update copyright header of all changed files to reflect changed in 2011
>> +
>> +should the debug binary really assert(0) if json syntax error? is it a
>> +good idea at the customer's? On the other hand, how to make sure a
>> +developer notices a syntax error when running tests?
>>
> 
> Perhaps it is time for us to have a DEBUG_WARN?

What would this macro do?
The context is that if a customer/support is troubleshooting a 
problematic query, using the optimizer trace and a debug binary, it may 
happen that she/he hits a case where the trace is not JSON-compliant 
(we, optimizer team, cannot guarantee that we have studied *all* code 
paths which can lead to generation of a trace; there are many more than 
what is exercised by the full mtr testsuite).
In that case, for the customer, the invalid-syntax trace is still worth 
looking at, informative, and a DBUG_ASSERT(0) is then a pure annoyance.
On the other hand, when I, developer, am modifying the optimizer and 
running the testsuite, I certainly want to be told if my changes lead to 
an invalid trace, and for this, DBUG_ASSERT(0) is perfect (it makes the 
test fail).
Maybe we could do a sql_print_warning() instead of DBUG_ASSERT(0); mtr 
warns when it sees an unexpected warning, it marks the test as failed, 
prints the warning on stderr, and returns 1 as exit code. I guess this 
would be good enough?

Thread
bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260) Guilhem Bichot19 Jan
Re: bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260)Davi Arnaut19 Jan
  • Re: bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260)Guilhem Bichot19 Jan
    • Re: bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260)Davi Arnaut19 Jan
      • Re: bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260)Guilhem Bichot20 Jan
    • Re: bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260)Bjorn Munch19 Jan
      • Re: bzr commit into mysql-next-mr-bugfixing branch (guilhem.bichot:3260)Davi Arnaut19 Jan