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.
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