Comment 4 for bug 1214274

Hi Alexey,

> I have to admit I don't understand anything from the above:

I was not clear enough.

> - what select and update queries are "forked" by xtrabackup?

Not by xtrabackup, but by test case. Test case executes selects/updates in background and xtrabackup should kill or not to kill them depending on arguments specified.

> - why does xtrabackup starting before forked processes are forked lead to a test failure? Which from those 2 failures does this case correspond to?

Xtrabackup may start before forked (by test) queries started justs because nothing prevents it.

> - what is case #2 (the comment mentions case 1 twice)
> - how can case #2 only happen for case #1?

I mixed case 1 (which is under ====== case 1 ====== section of test) and two cases of failure :)
Lets refer the one with innobackupex started early as "a)" - it is the "ubuntu-raring-64bit".
"b)" - centos5-32.

a) tried to test following
   - run update query which lasts 3 seconds
   - run select query witch lasts 3 seconds
   - run innobackupex which will kill all queries 5 seconds after FTWRL
   - as a result both queries and xtrabackup should succeed
   This is failed because innobackupex started to work earlier that queries in background and killed one of them.

> - how can xtrabackup "kill" its own connection? innobackupex may kill processes (but if it killed itself, it would fail differently?), and xtrabackup doesn't "own" any connections and doesn't kill anything.

I referred xtrabackup as product. innobackupex killed it's own connection, and the error is
innobackupex: Error:
Error executing 'SHOW MASTER STATUS': DBD::mysql::db selectrow_hashref failed: MySQL server has gone away

> Can you clarify?

I hope now things become little bit more clear.