Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2(EOL)
-
None
Description
--source include/have_innodb.inc
|
CREATE TABLE t (a INT) ENGINE=InnoDB; |
LOCK TABLES t AS t1 WRITE CONCURRENT, t AS t2 READ; |
|
10.2 7edadde72eb23e9110db8cea810c023104e9d15e |
mysqld: /data/src/10.2/sql/mdl.cc:2327: bool MDL_context::upgrade_shared_lock(MDL_ticket*, enum_mdl_type, double): Assertion `mdl_ticket->m_type == MDL_SHARED_UPGRADABLE || mdl_ticket->m_type == MDL_SHARED_NO_WRITE || mdl_ticket->m_type == MDL_SHARED_NO_READ_WRITE || mdl_ticket->m_type == MDL_SHARED_READ' failed.
|
170523 23:16:49 [ERROR] mysqld got signal 6 ;
|
|
|
#7 0x00007fa10084dee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
|
#8 0x00007fa1030be241 in MDL_context::upgrade_shared_lock (this=0x7fa0a8000c00, mdl_ticket=0x7fa0a8079470, new_type=MDL_SHARED_READ_ONLY, lock_wait_timeout=86400) at /data/src/10.2/sql/mdl.cc:2324
|
#9 0x00007fa102f6a3ee in lock_tables_open_and_lock_tables (thd=0x7fa0a8000b00, tables=0x7fa0a8012470) at /data/src/10.2/sql/sql_parse.cc:2800
|
#10 0x00007fa102f7020d in mysql_execute_command (thd=0x7fa0a8000b00) at /data/src/10.2/sql/sql_parse.cc:4876
|
#11 0x00007fa102f798f0 in mysql_parse (thd=0x7fa0a8000b00, rawbuf=0x7fa0a8012348 "LOCK TABLES t AS t1 WRITE CONCURRENT, t AS t2 READ", length=50, parser_state=0x7fa0f4094200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7874
|
#12 0x00007fa102f679c8 in dispatch_command (command=COM_QUERY, thd=0x7fa0a8000b00, packet=0x7fa0a81406b1 "LOCK TABLES t AS t1 WRITE CONCURRENT, t AS t2 READ", packet_length=50, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1812
|
#13 0x00007fa102f66338 in do_command (thd=0x7fa0a8000b00) at /data/src/10.2/sql/sql_parse.cc:1362
|
#14 0x00007fa1030b10cf in do_handle_one_connection (connect=0x7fa105f36420) at /data/src/10.2/sql/sql_connect.cc:1354
|
#15 0x00007fa1030b0e5c in handle_one_connection (arg=0x7fa105f36420) at /data/src/10.2/sql/sql_connect.cc:1260
|
#16 0x00007fa1034cad02 in pfs_spawn_thread (arg=0x7fa105e99d90) at /data/src/10.2/storage/perfschema/pfs.cc:1862
|
#17 0x00007fa102587494 in start_thread (arg=0x7fa0f4095700) at pthread_create.c:333
|
#18 0x00007fa10090a93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
Attachments
Activity
I'd either use the stronger lock or issue an error.
I think I'd prefer a stronger lock, if there's a good explanation why it's not an error. And here it is:
insert t1 select * from t1 |
this needs to read from and to write to the table. and it takes a stronger lock, there's no error here.
Hmm... I believe this example is not completely applicable, because semantically we have to take MDL_SHARED_WRITE in this case. Right?
But in this bug semantically we can allow concurrent reads (except for LOCK TABLE ... READ). The only reason why we wouldn't allow them is that we don't want to add a lot of code just to handle this edge case.
Yes, I just mean that the server takes a stronger lock. I could, probably, come with with a more complex example with a couple of triggers that require different locks on the same table and how prelocking handles it.
But I think it's enough to say that when many locks are requested, the stronger lock wins.
In our case requested locks will be MDL_SHARED_WRITE and MDL_SHARED_READ_ONLY. And the winner is out of sudden MDL_SHARED_NO_READ_WRITE. I don't think we had anything similar before MDL_SHARED_READ_ONLY was introduced.
I'm all for upgrading to MDL_SHARED_NO_READ_WRITE. Just trying to understand your arguments.
Even though table is locked multiple times connection can hold only one lock, the strongest one. Currently there's no lock having semantics suitable for the above test case, that is:
I can see the following possible fixes:
serg, what's your thinking?