Hi Rafal,
Rafal Somla, 12.01.2010 12:22:
> Hi Ingo,
>
> Thanks for clarifying this - I though that DEBUG_SYNC is active only in
> debug builds but you explained that this is not the case.
Normally it is active only in debug builds, but one *can* enable it
independent from debug. It has been designed as a compromise between low
overhead and usability. It should be good enough even for a production
server. But there is no obvious use case for it. One thing that could be
done, is running the test suite on a non-debug server, including the
test cases that require DEBUG_SYNC. As far as I know this has not been
done yet though.
>
> Ingo Strüwing wrote:
>>
>> Why has this been commented out in 5.6? The sync point
>> "before_execute_sql_command" is used in backup_bml_not_falcon and
>> backup_bml. Both are marked as "hang" or "timeout" in the backport test
>> failures table.
>>
>
> Good question. Have I done this (I don't think so)?
If I interpret the bzr history right, it was not you.
> Also, as far as I
> remember, my intention was that this synchronisation point is always hit
> whenever an SQL statement is executed - don't know why an exception is
> made for SQLCOM_SET_OPTION...
[We discussed it on IRC already. Here again for the public.]
It makes testing with DEBUG_SYNC a little more comfortable. Often one
needs to activate multiple sync points for a statement. The order of the
activations doesn't matter.
Without the exception though, SET DEBUG_SYNC =
'before_execute_sql_command ...' would need to be the last statement
before the target statement. Otherwise the next SET statement would
execute the sync point.
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
