Re: [Maria-developers] c75cbc1: MDEV-717 LP:1003679 - Wrong binlog order on concurrent DROP schema and

Hi, Alexey! convention below: when I start a comment with "btw" it means that you don't need to change anything, it's just a thought I had when looking at that line in the patch. On May 03, Alexey Botchkov wrote:
btw, generally this isn't necessary anymore, after-test checks verify that every test cleans up after itself.
+connect(con1,localhost,root,,);
btw, this works also without extra commas: connect(con1,localhost,root);
Hm... If the default connection signals "locked" before you start waiting for it now - will your test still work? You can test it by adding a sleep right after "connection con1". (don't commit the sleep, of course, it's just to way to verify whether the test case is valid) Alternatively, in many places tests wait for a connection to reach the certain debug_sync point with, like: let $wait_condition= select count(*) = 1 from information_schema.processlist where state like "debug sync point: wait_drop_db_name_locked%"; source include/wait_condition.inc;
+SET DEBUG_SYNC= "sp_create_routine_started SIGNAL release"; +--error 0,ER_BAD_DB_ERROR
why? Do you mean that even with your sync points the specific execution order if not guaranteed?
could you use "before_wait_locked_pname" sync point instead? It's at the beginning of lock_object_name().
Could you use "after_wait_locked_schema_name" sync point instead? It's the one at the end of lock_schema_name().
Regards, Sergei Chief Architect MariaDB and security@mariadb.org

Hm... If the default connection signals "locked" before you start waiting for it now - will your test still work?
Well the DEBUG_SYNC manual seems to be explicit about it: " A signal remains in effect until it is overwritten. If conn1 signals 'opened' before conn2 reaches 'now', conn2 will still find the 'opened' signal. It does not wait in this case. "
+SET DEBUG_SYNC= "sp_create_routine_started SIGNAL release"; +--error 0,ER_BAD_DB_ERROR
why? Do you mean that even with your sync points the specific execution order if not guaranteed?
Not sure i understand your question properly. But i mean, getting the BAD_DB_ERROR is the execution result i desire here. Best regards. HF 03.05.2016 21:38, Sergei Golubchik wrote:

Hi, Alexey! On May 04, Alexey Botchkov wrote:
Great. Then replication tests overcomplicate it, as usual.
Your test here expects "either ER_BAD_DB_ERROR or a success". I asked - does that mean that even with your debug_sync points the result is still non-deterministic? Regards, Sergei Chief Architect MariaDB and security@mariadb.org
participants (2)
-
Alexey Botchkov
-
Sergei Golubchik