Hi!
On Mar 12, Ingo Strüwing wrote:
> Hi Sergei,
>
> Sergei Golubchik, 12.03.2008 15:30:
> ...
> > Is it difficult to support global debug_sync ?
>
> Yes. The actions are stored in an array referenced by THD. Every thread
> can request different actions for the same sync point.
>
> We could have a global array too. And add actions to it when SET GLOBAL
> is given. But then each sync point would need to search in two arrays. A
> local action would supersede the global action. But if there is none, it
> would search for a global one.
How would you, without a global variable, synchronize with threads that
are not connection threads ?
Okay, for SQL slave thread you can, of course, replicate something like
UPDATE dummytable SET dummyfield=(@@session.debug_sync='...')
but this trick has limited applicability :)
> Another problem is the semantics of resetting the global actions. CLEAR
> or RESET is used to remove an action. Now one could define that CLEAR
> removes the local action if present or the global action if the local
> one is not present. RESET clears everything, local and global? Or global
> only if no local action is present?
just like @@global.debug works. CLEAR and RESET on the global level
affect only that global array of actions you've described above.
Local arrays are not affected.
> > 2. Anyway, the error message is wrong. A generic mistake - you
> > cannot use "global variable" as a parameter, as it breaks localized
> > error messages,
>
> Hm. I was fooled by other applications of this error message, like:
> "BASE TABLE" or "TRIGGERNAME".
It's a questionable trick, I agree. Especially the second one -
TRIGGERNAME - it is just wrong. BASE TABLE is kind of okay, it's exactly
what SHOW TABLES displays, so it's used in the error message as the "value
of the appropriate column in the SHOW TABLES output" not as an English phrase.
And as such it does not need to be translated.
Regards / Mit vielen Grüssen,
Sergei
--
__ ___ ___ ____ __
/ |/ /_ __/ __/ __ \/ / Sergei Golubchik <serg@stripped>
/ /|_/ / // /\ \/ /_/ / /__ Principal Software Developer/Server Architect
/_/ /_/\_, /___/\___\_\___/ MySQL GmbH, Dachauer Str. 37, D-80335 München
<___/ Geschäftsführer: Kaj Arnö - HRB
München 162140
