Hi Andrei,
Andrei Elkin, 05.03.2010 12:42:
...
> DEBUG_SYNC can definitely survive w/o DBUG package as well as DEBUG_ prefix.
> Why would not it become as ambitious as to replace the user GET/RELEASE
> locks entirely (or to convert internal handlers to exploit SYNC)?
My initial idea was to have a "Test Synchronization Facility". Monty did
even suggest to have an SQL syntax extension: TEST SYNC[CHRONIZE] ...
Architects insisted in the DEBUG prefix. So it seemed obvious to enable
it only in a debug server by default.
User level locks are for the user. One can take profit from them without
knowing anything about the source code. I'm sure that users use them. I
suggest, not to touch them.
...
> Thanks, i am getting more and more into this feature.
I'm always calling it a "facility", not a "feature". I like to keep the
latter for things that the users can take profit from. DEBUG_SYNC is
helpful to developers only. One needs to know the exact location of the
sync points in the code.
...
> And I would have to replace couple of more DBUG_SYNC_POINT occurrences
> as well.
A grep found just three of them in current 5.5 code.
...
> Got couple of ideas while writing the mail:
>
> For init time:
>
> - inhering THD context (a part like user vars) from thread that start
> the replication thread
Possible - if the starting thread can tell, who is responsible for its
start. A starting event thread may not be able to tell.
The calling thread would need to prepare its own action list so that it
is valid for the target thread. Could that cause conflicts (a sync point
in common code triggers in the calling thread before the target is started)?
>
> For main loop time:
>
> - to engineer a debug_sync replication event
I guess that would be a very specific solution for system threads
involved in replication.
Regards
Ingo
--
Ingo Strüwing, Database Group
Sun Microsystems GmbH, Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Geschäftsführer: Thomas Schröder, Wolfgang Engels
Vorsitzender des Aufsichtsrates: Martin Häring HRB München 161028
