This file is indexed.

/usr/lib/mysql-testsuite/r/lock_sync.result is in percona-server-test-5.6 5.6.22-rel71.0-0ubuntu4.

This file is owned by root:root, with mode 0o644.

The actual contents of the file can be viewed below.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
#
# Test how we handle locking in various cases when
# we read data from MyISAM tables.
#
# In this test we mostly check that the SQL-layer correctly
# determines the type of thr_lock.c lock for a table being
# read.
# I.e. that it disallows concurrent inserts when the statement
# is going to be written to the binary log and therefore
# should be serialized, and allows concurrent inserts when
# such serialization is not necessary (e.g. when 
# the statement is not written to binary log).
#
# Force concurrent inserts to be performed even if the table
# has gaps. This allows to simplify clean up in scripts
# used below (instead of backing up table being inserted
# into and then restoring it from backup at the end of the
# script we can simply delete rows which were inserted).
set @old_concurrent_insert= @@global.concurrent_insert;
set @@global.concurrent_insert= 2;
select @@global.concurrent_insert;
@@global.concurrent_insert
ALWAYS
# Prepare playground by creating tables, views,
# routines and triggers used in tests.
drop table if exists t0, t1, t2, t3, t4, t5;
drop view if exists v1, v2;
drop procedure if exists p1;
drop procedure if exists p2;
drop procedure if exists p3;
drop function if exists f1;
drop function if exists f2;
drop function if exists f3;
drop function if exists f4;
drop function if exists f5;
drop function if exists f6;
drop function if exists f7;
drop function if exists f8;
drop function if exists f9;
drop function if exists f10;
drop function if exists f11;
drop function if exists f12;
drop function if exists f13;
drop function if exists f14;
drop function if exists f15;
drop function if exists f16;
drop function if exists f17;
create table t1 (i int primary key);
insert into t1 values (1), (2), (3), (4), (5);
create table t2 (j int primary key);
insert into t2 values (1), (2), (3), (4), (5);
create table t3 (k int primary key);
insert into t3 values (1), (2), (3);
create table t4 (l int primary key);
insert into t4 values (1);
create table t5 (l int primary key);
insert into t5 values (1);
create view v1 as select i from t1;
create view v2 as select j from t2 where j in (select i from t1);
create procedure p1(k int) insert into t2 values (k);
create function f1() returns int
begin
declare j int;
select i from t1 where i = 1 into j;
return j;
end|
create function f2() returns int
begin
declare k int;
select i from t1 where i = 1 into k;
insert into t2 values (k + 5);
return 0;
end|
create function f3() returns int
begin
return (select i from t1 where i = 3);
end|
create function f4() returns int
begin
if (select i from t1 where i = 3) then
return 1;
else
return 0;
end if;
end|
create function f5() returns int
begin
insert into t2 values ((select i from t1 where i = 1) + 5);
return 0;
end|
create function f6() returns int
begin
declare k int;
select i from v1 where i = 1 into k;
return k;
end|
create function f7() returns int
begin
declare k int;
select j from v2 where j = 1 into k;
return k;
end|
create function f8() returns int
begin
declare k int;
select i from v1 where i = 1 into k;
insert into t2 values (k+5);
return k;
end|
create function f9() returns int
begin
update v2 set j=j+10 where j=1;
return 1;
end|
create function f10() returns int
begin
return f1();
end|
create function f11() returns int
begin
declare k int;
set k= f1();
insert into t2 values (k+5);
return k;
end|
create function f12(p int) returns int
begin
insert into t2 values (p);
return p;
end|
create function f13(p int) returns int
begin
return p;
end|
create procedure p2(inout p int)
begin
select i from t1 where i = 1 into p;
end|
create function f14() returns int
begin
declare k int;
call p2(k);
insert into t2 values (k+5);
return k;
end|
create function f15() returns int
begin
declare k int;
call p2(k);
return k;
end|
create function f16() returns int
begin
create temporary table if not exists temp1 (a int);
insert into temp1 select * from t1;
drop temporary table temp1;
return 1;
end|
create function f17() returns int
begin
declare j int;
select i from t1 where i = 1 into j;
call p3;
return 1;
end|
create procedure p3()
begin
create temporary table if not exists temp1 (a int);
insert into temp1 select * from t1;
drop temporary table temp1;
end|
create trigger t4_bi before insert on t4 for each row
begin
declare k int;
select i from t1 where i=1 into k;
set new.l= k+1;
end|
create trigger t4_bu before update on t4 for each row
begin
if (select i from t1 where i=1) then
set new.l= 2;
end if;
end|
create trigger t4_bd before delete on t4 for each row
begin
if !(select i from v1 where i=1) then
signal sqlstate '45000';
end if;
end|
create trigger t5_bi before insert on t5 for each row
begin
set new.l= f1()+1;
end|
create trigger t5_bu before update on t5 for each row
begin
declare j int;
call p2(j);
set new.l= j + 1;
end|
#
# Set common variables to be used by the scripts
# called below.
#
# Switch to connection 'con1'.
# Cache all functions used in the tests below so statements
# calling them won't need to open and lock mysql.proc table
# and we can assume that each statement locks its tables
# once during its execution.
show create procedure p1;
show create procedure p2;
show create procedure p3;
show create function f1;
show create function f2;
show create function f3;
show create function f4;
show create function f5;
show create function f6;
show create function f7;
show create function f8;
show create function f9;
show create function f10;
show create function f11;
show create function f12;
show create function f13;
show create function f14;
show create function f15;
show create function f16;
show create function f17;
# Switch back to connection 'default'.
#
# 1. Statements that read tables and do not use subqueries.
#
#
# 1.1 Simple SELECT statement.
#
# No locks are necessary as this statement won't be written
# to the binary log and thanks to how MyISAM works SELECT
# will see version of the table prior to concurrent insert.
Success: 'select * from t1' allows concurrent inserts into 't1'.
#
# 1.2 Multi-UPDATE statement.
#
# Has to take shared locks on rows in the table being read as this
# statement will be written to the binary log and therefore should
# be serialized with concurrent statements.
Success: 'update t2, t1 set j= j - 1 where i = j' doesn't allow concurrent inserts into 't1'.
#
# 1.3 Multi-DELETE statement.
#
# The above is true for this statement as well.
Success: 'delete t2 from t1, t2 where i = j' doesn't allow concurrent inserts into 't1'.
#
# 1.4 DESCRIBE statement.
#
# This statement does not really read data from the
# target table and thus does not take any lock on it.
# We check this for completeness of coverage.
lock table t1 write;
# Switching to connection 'con1'.
# This statement should not be blocked.
describe t1;
# Switching to connection 'default'.
unlock tables;
#
# 1.5 SHOW statements.
# 
# The above is true for SHOW statements as well.
lock table t1 write;
# Switching to connection 'con1'.
# These statements should not be blocked.
show keys from t1;
# Switching to connection 'default'.
unlock tables;
#
# 2. Statements which read tables through subqueries.
#
#
# 2.1 CALL with a subquery.
# 
# A strong lock is not necessary as this statement is not
# written to the binary log as a whole (it is written
# statement-by-statement).
Success: 'call p1((select i + 5 from t1 where i = 1))' allows concurrent inserts into 't1'.
#
# 2.2 CREATE TABLE with a subquery.
#
# Has to take a strong lock on the table being read as
# this statement is written to the binary log and therefore
# should be serialized with concurrent statements.
Success: 'create table t0 select * from t1' doesn't allow concurrent inserts into 't1'.
drop table t0;
Success: 'create table t0 select j from t2 where j in (select i from t1)' doesn't allow concurrent inserts into 't1'.
drop table t0;
#
# 2.3 DELETE with a subquery.
#
# The above is true for this statement as well.
Success: 'delete from t2 where j in (select i from t1)' doesn't allow concurrent inserts into 't1'.
#
# 2.4 MULTI-DELETE with a subquery.
#
# Same is true for this statement as well.
Success: 'delete t2 from t3, t2 where k = j and j in (select i from t1)' doesn't allow concurrent inserts into 't1'.
#
# 2.5 DO with a subquery.
#
# A strong lock is not necessary as it is not logged.
Success: 'do (select i from t1 where i = 1)' allows concurrent inserts into 't1'.
#
# 2.6 INSERT with a subquery.
#
# Has to take a strong lock on the table being read as
# this statement is written to the binary log and therefore
# should be serialized with concurrent inserts.
Success: 'insert into t2 select i+5 from t1' doesn't allow concurrent inserts into 't1'.
Success: 'insert into t2 values ((select i+5 from t1 where i = 4))' doesn't allow concurrent inserts into 't1'.
#
# 2.7 LOAD DATA with a subquery.
# 
# The above is true for this statement as well.
Success: 'load data infile '../../std_data/rpl_loaddata.dat' into table t2 (@a, @b) set j= @b + (select i from t1 where i = 1)' doesn't allow concurrent inserts into 't1'.
#
# 2.8 REPLACE with a subquery.
# 
# Same is true for this statement as well.
Success: 'replace into t2 select i+5 from t1' doesn't allow concurrent inserts into 't1'.
Success: 'replace into t2 values ((select i+5 from t1 where i = 4))' doesn't allow concurrent inserts into 't1'.
#
# 2.9 SELECT with a subquery.
#
# Strong locks are not necessary as this statement is not written
# to the binary log and thanks to how MyISAM works this statement
# sees a version of the table prior to the concurrent insert.
Success: 'select * from t2 where j in (select i from t1)' allows concurrent inserts into 't1'.
#
# 2.10 SET with a subquery.
#
# The same is true for this statement as well.
Success: 'set @a:= (select i from t1 where i = 1)' allows concurrent inserts into 't1'.
#
# 2.11 SHOW with a subquery.
# 
# And for this statement too.
Success: 'show tables from test where Tables_in_test = 't2' and (select i from t1 where i = 1)' allows concurrent inserts into 't1'.
Success: 'show columns from t2 where (select i from t1 where i = 1)' allows concurrent inserts into 't1'.
#
# 2.12 UPDATE with a subquery.
#
# Has to take a strong lock on the table being read as
# this statement is written to the binary log and therefore
# should be serialized with concurrent inserts.
Success: 'update t2 set j= j-10 where j in (select i from t1)' doesn't allow concurrent inserts into 't1'.
#
# 2.13 MULTI-UPDATE with a subquery.
#
# Same is true for this statement as well.
Success: 'update t2, t3 set j= j -10 where j=k and j in (select i from t1)' doesn't allow concurrent inserts into 't1'.
#
# 3. Statements which read tables through a view.
#
#
# 3.1 SELECT statement which uses some table through a view.
#
# Since this statement is not written to the binary log and
# an old version of the table is accessible thanks to how MyISAM
# handles concurrent insert, no locking is necessary.
Success: 'select * from v1' allows concurrent inserts into 't1'.
Success: 'select * from v2' allows concurrent inserts into 't1'.
Success: 'select * from t2 where j in (select i from v1)' allows concurrent inserts into 't1'.
Success: 'select * from t3 where k in (select j from v2)' allows concurrent inserts into 't1'.
#
# 3.2 Statements which modify a table and use views.
#
# Since such statements are going to be written to the binary
# log they need to be serialized against concurrent statements
# and therefore should take strong locks on the data read.
Success: 'update t2 set j= j-10 where j in (select i from v1)' doesn't allow concurrent inserts into 't1'.
Success: 'update t3 set k= k-10 where k in (select j from v2)' doesn't allow concurrent inserts into 't1'.
Success: 'update t2, v1 set j= j-10 where j = i' doesn't allow concurrent inserts into 't1'.
Success: 'update v2 set j= j-10 where j = 3' doesn't allow concurrent inserts into 't1'.
#
# 4. Statements which read tables through stored functions.
#
#
# 4.1 SELECT/SET with a stored function which does not 
#     modify data and uses SELECT in its turn.
#
# There is no need to take strong locks on the table
# being selected from in SF as the call to such function
# won't get into the binary log.
Success: 'select f1()' allows concurrent inserts into 't1'.
Success: 'set @a:= f1()' allows concurrent inserts into 't1'.
#
# 4.2 INSERT (or other statement which modifies data) with
#     a stored function which does not modify data and uses
#     SELECT.
#
# Since such statement is written to the binary log it should
# be serialized with concurrent statements affecting the data
# it uses. Therefore it should take strong lock on the data
# it reads.
Success: 'insert into t2 values (f1() + 5)' doesn't allow concurrent inserts into 't1'.
#
# 4.3 SELECT/SET with a stored function which
#     reads and modifies data.
#
# Since a call to such function is written to the binary log,
# it should be serialized with concurrent statements affecting
# the data it uses. Hence, a strong lock on the data read
# should be taken.
Success: 'select f2()' doesn't allow concurrent inserts into 't1'.
Success: 'set @a:= f2()' doesn't allow concurrent inserts into 't1'.
#
# 4.4. SELECT/SET with a stored function which does not
#      modify data and reads a table through subselect
#      in a control construct.
#
# Call to this function won't get to the
# binary log and thus no strong lock is needed.
Success: 'select f3()' allows concurrent inserts into 't1'.
Success: 'set @a:= f3()' allows concurrent inserts into 't1'.
Success: 'select f4()' allows concurrent inserts into 't1'.
Success: 'set @a:= f4()' allows concurrent inserts into 't1'.
#
# 4.5. INSERT (or other statement which modifies data) with
#      a stored function which does not modify data and reads
#      the table through a subselect in one of its control
#      constructs.
#
# Since such statement is written to the binary log it should
# be serialized with concurrent statements affecting data it
# uses. Therefore it should take a strong lock on the data
# it reads.
Success: 'insert into t2 values (f3() + 5)' doesn't allow concurrent inserts into 't1'.
Success: 'insert into t2 values (f4() + 6)' doesn't allow concurrent inserts into 't1'.
#
# 4.6 SELECT/SET which uses a stored function with
#      DML which reads a table via a subquery.
#
# Since call to such function is written to the binary log
# it should be serialized with concurrent statements.
# Hence reads should take a strong lock.
Success: 'select f5()' doesn't allow concurrent inserts into 't1'.
Success: 'set @a:= f5()' doesn't allow concurrent inserts into 't1'.
#
# 4.7 SELECT/SET which uses a stored function which
#     doesn't modify data and reads tables through
#     a view.
#
# Calls to such functions won't get into
# the binary log and thus don't need strong
# locks.
Success: 'select f6()' allows concurrent inserts into 't1'.
Success: 'set @a:= f6()' allows concurrent inserts into 't1'.
Success: 'select f7()' allows concurrent inserts into 't1'.
Success: 'set @a:= f7()' allows concurrent inserts into 't1'.
#
# 4.8 INSERT which uses stored function which
#     doesn't modify data and reads a table
#     through a view.
#
# Since such statement is written to the binary log and
# should be serialized with concurrent statements affecting
# the data it uses. Therefore it should take a strong lock on
# the table it reads.
Success: 'insert into t3 values (f6() + 5)' doesn't allow concurrent inserts into 't1'.
Success: 'insert into t3 values (f7() + 5)' doesn't allow concurrent inserts into 't1'.
#
# 4.9 SELECT which uses a stored function which
#     modifies data and reads tables through a view.
#
# Since a call to such function is written to the binary log
# it should be serialized with concurrent statements.
# Hence, reads should take strong locks.
Success: 'select f8()' doesn't allow concurrent inserts into 't1'.
Success: 'select f9()' doesn't allow concurrent inserts into 't1'.
#
# 4.10 SELECT which uses a stored function which doesn't modify
#      data and reads a table indirectly, by calling another
#      function.
#
# Calls to such functions won't get into the binary
# log and thus don't need to acquire strong locks.
Success: 'select f10()' allows concurrent inserts into 't1'.
#
# 4.11 INSERT which uses a stored function which doesn't modify
#      data and reads a table indirectly, by calling another
#      function. 
#
# Since such statement is written to the binary log, it should
# be serialized with concurrent statements affecting the data it
# uses. Therefore it should take strong locks on data it reads.
Success: 'insert into t2 values (f10() + 5)' doesn't allow concurrent inserts into 't1'.
#
# 4.12 SELECT which uses a stored function which modifies
#      data and reads a table indirectly, by calling another
#      function. 
#
# Since a call to such function is written to the binary log
# it should be serialized from concurrent statements.
# Hence, read should take a strong lock.
Success: 'select f11()' doesn't allow concurrent inserts into 't1'.
#
# 4.13 SELECT that reads a table through a subquery passed
#      as a parameter to a stored function which modifies
#      data.
#
# Even though a call to this function is written to the
# binary log, values of its parameters are written as literals.
# So there is no need to acquire strong locks for tables used in
# the subquery.
Success: 'select f12((select i+10 from t1 where i=1))' allows concurrent inserts into 't1'.
#
# 4.14 INSERT that reads a table via a subquery passed
#      as a parameter to a stored function which doesn't
#      modify data.
#
# Since this statement is written to the binary log it should
# be serialized with concurrent statements affecting the data it
# uses. Therefore it should take strong locks on the data it reads.
Success: 'insert into t2 values (f13((select i+10 from t1 where i=1)))' doesn't allow concurrent inserts into 't1'.
#
# 4.15 SELECT/SET with a stored function which 
#      inserts data into a temporary table using
#      SELECT on t1.
#
# Since this statement is written to the binary log it should
# be serialized with concurrent statements affecting the data it
# uses. Therefore it should take strong locks on the data it reads.
Success: 'select f16()' doesn't allow concurrent inserts into 't1'.
Success: 'set @a:= f16()' doesn't allow concurrent inserts into 't1'.
#
# 4.16 SELECT/SET with a stored function which call procedure
#      which inserts data into a temporary table using
#      SELECT on t1.
#
# Since this statement is written to the binary log it should
# be serialized with concurrent statements affecting the data it
# uses. Therefore it should take strong locks on the data it reads.
Success: 'select f17()' doesn't allow concurrent inserts into 't1'.
Success: 'set @a:= f17()' doesn't allow concurrent inserts into 't1'.
#
# 5. Statements that read tables through stored procedures.
#
#
# 5.1 CALL statement which reads a table via SELECT.
#
# Since neither this statement nor its components are
# written to the binary log, there is no need to take
# strong locks on the data it reads.
Success: 'call p2(@a)' allows concurrent inserts into 't1'.
#
# 5.2 Function that modifies data and uses CALL, 
#     which reads a table through SELECT.
#
# Since a call to such function is written to the binary
# log, it should be serialized with concurrent statements.
# Hence, in this case reads should take strong locks on data.
Success: 'select f14()' doesn't allow concurrent inserts into 't1'.
#
# 5.3 SELECT that calls a function that doesn't modify data and
#     uses a CALL statement that reads a table via SELECT.
#
# Calls to such functions won't get into the binary
# log and thus don't need to acquire strong locks.
Success: 'select f15()' allows concurrent inserts into 't1'.
#
# 5.4 INSERT which calls function which doesn't modify data and
#     uses CALL statement which reads table through SELECT.
#
# Since such statement is written to the binary log it should
# be serialized with concurrent statements affecting data it
# uses. Therefore it should take strong locks on data it reads.
Success: 'insert into t2 values (f15()+5)' doesn't allow concurrent inserts into 't1'.
#
# 6. Statements that use triggers.
#
#
# 6.1 Statement invoking a trigger that reads table via SELECT.
#
# Since this statement is written to the binary log it should
# be serialized with concurrent statements affecting the data
# it uses. Therefore, it should take strong locks on the data
# it reads.
Success: 'insert into t4 values (2)' doesn't allow concurrent inserts into 't1'.
#
# 6.2 Statement invoking a trigger that reads table through
#     a subquery in a control construct.
#
# The above is true for this statement as well.
Success: 'update t4 set l= 2 where l = 1' doesn't allow concurrent inserts into 't1'.
#
# 6.3 Statement invoking a trigger that reads a table through
#     a view.
#
# And for this statement.
Success: 'delete from t4 where l = 1' doesn't allow concurrent inserts into 't1'.
#
# 6.4 Statement invoking a trigger that reads a table through
#     a stored function.
#
# And for this statement.
Success: 'insert into t5 values (2)' doesn't allow concurrent inserts into 't1'.
#
# 6.5 Statement invoking a trigger that reads a table through
#     stored procedure.
#
# And for this statement.
Success: 'update t5 set l= 2 where l = 1' doesn't allow concurrent inserts into 't1'.
# Clean-up.
drop function f1;
drop function f2;
drop function f3;
drop function f4;
drop function f5;
drop function f6;
drop function f7;
drop function f8;
drop function f9;
drop function f10;
drop function f11;
drop function f12;
drop function f13;
drop function f14;
drop function f15;
drop function f16;
drop function f17;
drop view v1, v2;
drop procedure p1;
drop procedure p2;
drop procedure p3;
drop table t1, t2, t3, t4, t5;
set @@global.concurrent_insert= @old_concurrent_insert;
#
# Test for bug #45143 "All connections hang on concurrent ALTER TABLE".
#
# Concurrent execution of statements which required weak write lock
# (TL_WRITE_ALLOW_WRITE) on several instances of the same table and
# statements which tried to acquire stronger write lock (TL_WRITE,
# TL_WRITE_ALLOW_READ) on this table might have led to deadlock.
drop table if exists t1;
drop view if exists v1;
# Create auxiliary connections used through the test.
# Reset DEBUG_SYNC facility before using it.
set debug_sync= 'RESET';
# Turn off logging so calls to locking subsystem performed
# for general_log table won't interfere with our test.
set @old_general_log = @@global.general_log;
set @@global.general_log= OFF;
create table t1 (i int) engine=InnoDB;
# We have to use view in order to make LOCK TABLES avoid
# acquiring SNRW metadata lock on table.
create view v1 as select * from t1;
insert into t1 values (1);
# Prepare user lock which will be used for resuming execution of
# the first statement after it acquires TL_WRITE_ALLOW_WRITE lock.
select get_lock("lock_bug45143_wait", 0);
get_lock("lock_bug45143_wait", 0)
1
# Switch to connection 'con_bug45143_1'.
# Sending:
insert into t1 values (get_lock("lock_bug45143_wait", 100));;
# Switch to connection 'con_bug45143_2'.
# Wait until the above INSERT takes TL_WRITE_ALLOW_WRITE lock on 't1'
# and then gets blocked on user lock 'lock_bug45143_wait'.
# Ensure that upcoming SELECT waits after acquiring TL_WRITE_ALLOW_WRITE
# lock for the first instance of 't1'.
set debug_sync='thr_multi_lock_after_thr_lock SIGNAL parked WAIT_FOR go';
# Sending:
select count(*) > 0 from t1 as a, t1 as b for update;;
# Switch to connection 'con_bug45143_3'.
# Wait until the above SELECT ... FOR UPDATE is blocked after
# acquiring lock for the the first instance of 't1'.
set debug_sync= 'now WAIT_FOR parked';
# Send LOCK TABLE statement which will try to get TL_WRITE lock on 't1':
lock table v1 write;;
# Switch to connection 'default'.
# Wait until this LOCK TABLES statement starts waiting for table lock.
# Allow SELECT ... FOR UPDATE to resume.
# Since it already has TL_WRITE_ALLOW_WRITE lock on the first instance
# of 't1' it should be able to get lock on the second instance without
# waiting, even although there is another thread which has such lock
# on this table and also there is a thread waiting for a TL_WRITE on it.
set debug_sync= 'now SIGNAL go';
# Switch to connection 'con_bug45143_2'.
# Reap SELECT ... FOR UPDATE
count(*) > 0
1
# Switch to connection 'default'.
# Resume execution of the INSERT statement.
select release_lock("lock_bug45143_wait");
release_lock("lock_bug45143_wait")
1
# Switch to connection 'con_bug45143_1'.
# Reap INSERT statement.
# In Statement and Mixed replication mode we get here "Unsafe 
# for binlog" warnings. In row mode there are no warnings.
# Hide the discrepancy.
# Switch to connection 'con_bug45143_3'.
# Reap LOCK TABLES statement.
unlock tables;
# Switch to connection 'default'.
# Do clean-up.
set debug_sync= 'RESET';
set @@global.general_log= @old_general_log;
drop view v1;
drop table t1;
#
# Bug#50821 Deadlock between LOCK TABLES and ALTER TABLE
#
DROP TABLE IF EXISTS t1, t2;
CREATE TABLE t1(id INT);
CREATE TABLE t2(id INT);
# Connection con2
START TRANSACTION;
SELECT * FROM t1;
id
# Connection default
# Sending:
ALTER TABLE t1 ADD COLUMN j INT;
# Connection con2
# This used to cause a deadlock.
INSERT INTO t2 SELECT * FROM t1;
COMMIT;
# Connection default
# Reaping ALTER TABLE t1 ADD COLUMN j INT
DROP TABLE t1, t2;
#
# Bug#51391 Deadlock involving events during rqg_info_schema test
#
CREATE EVENT e1 ON SCHEDULE EVERY 5 HOUR DO SELECT 1;
CREATE EVENT e2 ON SCHEDULE EVERY 5 HOUR DO SELECT 2;
# Connection con1
SET DEBUG_SYNC="before_lock_tables_takes_lock SIGNAL drop WAIT_FOR query";
# Sending:
DROP EVENT e1;;
# Connection default
SET DEBUG_SYNC="now WAIT_FOR drop";
SELECT name FROM mysql.event, INFORMATION_SCHEMA.GLOBAL_VARIABLES
WHERE definer = VARIABLE_VALUE;
name
SET DEBUG_SYNC="now SIGNAL query";
# Connection con1
# Reaping: DROP EVENT t1
# Connection default
DROP EVENT e2;
SET DEBUG_SYNC="RESET";
#
# Bug#55930 Assertion `thd->transaction.stmt.is_empty() ||
#           thd->in_sub_stmt || (thd->state..
#
DROP TABLE IF EXISTS t1;
CREATE TABLE t1(a INT) engine=InnoDB;
INSERT INTO t1 VALUES (1), (2);
# Note: This test now provides coverage for the scenario where
# opening of table during analyze phase of OPTIMIZE TABLE
# fails (instead of original coverage for open_ltable() code).
# Connection con1
SET SESSION lock_wait_timeout= 1;
SET DEBUG_SYNC= 'ha_admin_open_ltable SIGNAL opti_recreate WAIT_FOR opti_analyze';
# Sending:
OPTIMIZE TABLE t1;
# Connection con2
SET DEBUG_SYNC= 'now WAIT_FOR opti_recreate';
SET DEBUG_SYNC= 'after_lock_tables_takes_lock SIGNAL thrlock WAIT_FOR release_thrlock';
# Sending:
LOCK TABLES t1 WRITE;
# Connection default
SET DEBUG_SYNC= 'now WAIT_FOR thrlock';
SET DEBUG_SYNC= 'now SIGNAL opti_analyze';
# Connection con1
# Reaping: OPTIMIZE TABLE t1
Table	Op	Msg_type	Msg_text
test.t1	optimize	note	Table does not support optimize, doing recreate + analyze instead
test.t1	optimize	error	Lock wait timeout exceeded; try restarting transaction
test.t1	optimize	status	Operation failed
Warnings:
Error	1205	Lock wait timeout exceeded; try restarting transaction
SET DEBUG_SYNC= 'now SIGNAL release_thrlock';
# Connection con2
# Reaping: LOCK TABLES t1 WRITE
# Connection default
DROP TABLE t1;
SET DEBUG_SYNC= 'RESET';
#
# Bug#57130 crash in Item_field::print during SHOW CREATE TABLE or VIEW
#
DROP TABLE IF EXISTS t1;
DROP VIEW IF EXISTS v1;
DROP FUNCTION IF EXISTS f1;
CREATE TABLE t1(a INT);
CREATE FUNCTION f1() RETURNS INTEGER RETURN 1;
CREATE VIEW v1 AS SELECT * FROM t1 WHERE f1() = 1;
DROP FUNCTION f1;
# Connection con1
SET DEBUG_SYNC= 'open_tables_after_open_and_process_table SIGNAL opened WAIT_FOR dropped EXECUTE 2';
# Sending:
SHOW CREATE VIEW v1;
# Connection con2
SET DEBUG_SYNC= 'now WAIT_FOR opened';
SET DEBUG_SYNC= 'now SIGNAL dropped';
SET DEBUG_SYNC= 'now WAIT_FOR opened';
# Sending:
FLUSH TABLES;
# Connection default
# Waiting for FLUSH TABLES to be blocked.
SET DEBUG_SYNC= 'now SIGNAL dropped';
# Connection con1
# Reaping: SHOW CREATE VIEW v1
View	Create View	character_set_client	collation_connection
v1	CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY DEFINER VIEW `v1` AS select `t1`.`a` AS `a` from `t1` where (`f1`() = 1)	latin1	latin1_swedish_ci
Warnings:
Warning	1356	View 'test.v1' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
# Connection con2
# Reaping: FLUSH TABLES
# Connection default
SET DEBUG_SYNC= 'RESET';
DROP VIEW v1;
DROP TABLE t1;
#
#Bug#18110156: RECREATE+ANALYZE OPTIMIZE TABLE T AND ONLINE 
#              ALTER TABLE T MAY DEADLOCK
CREATE TABLE t1 (fld1 INT) ENGINE=InnoDB;
connection con1;
SET DEBUG_SYNC= 'before_lock_tables_takes_lock SIGNAL before_thr_lock WAIT_FOR do_thr_lock EXECUTE 3';
SET DEBUG_SYNC= 'ha_admin_open_ltable SIGNAL opti_recreate WAIT_FOR opti_analyze';
OPTIMIZE TABLE t1;
connection con2;
# Skip thr_lock acquisition during the initial phase of OPTIMIZE TABLE
SET DEBUG_SYNC= 'now WAIT_FOR before_thr_lock';
SET DEBUG_SYNC= 'now SIGNAL do_thr_lock';
# Skip thr_lock acquisition during the recreate phase of OPTIMIZE TABLE
SET DEBUG_SYNC= 'now WAIT_FOR before_thr_lock';
SET DEBUG_SYNC= 'now SIGNAL do_thr_lock';
SET DEBUG_SYNC= 'now WAIT_FOR opti_recreate';
SET DEBUG_SYNC= 'alter_table_inplace_after_lock_downgrade SIGNAL lock_downgraded
WAIT_FOR finish_alter';
ALTER TABLE t1 ADD INDEX index1(fld1), ALGORITHM=INPLACE, LOCK=NONE;
#Without the patch, the test case hangs.
connection default;
SET DEBUG_SYNC= 'now WAIT_FOR lock_downgraded';
SET DEBUG_SYNC= 'now SIGNAL opti_analyze';
SET DEBUG_SYNC= 'now WAIT_FOR before_thr_lock';
SET DEBUG_SYNC= 'now SIGNAL finish_alter';
SET DEBUG_SYNC= 'now SIGNAL do_thr_lock';
#Reap: OPTIMIZE TABLE t1
connection con1;
Table	Op	Msg_type	Msg_text
test.t1	optimize	note	Table does not support optimize, doing recreate + analyze instead
test.t1	optimize	status	OK
#Reap: ALTER TABLE t1
connection con2;
#Clean up.
DROP TABLE t1;
SET DEBUG_SYNC= 'RESET';
#
# Bug#19070633 - POSSIBLE ACCESS TO FREED MEMORY IN IS_FREE_LOCK() AND IS_USED_LOCK().
#
# Verifying issue for IS_FREE_LOCK() function.
SELECT GET_LOCK("lock_19070633", 600);
GET_LOCK("lock_19070633", 600)
1
connect  con1, localhost, root,,;
# Waiting after getting user level lock info and releasing mutex.
SET DEBUG_SYNC= 'after_getting_user_level_lock_info SIGNAL parked WAIT_FOR go';
# Sending: SELECT IS_FREE_LOCK("lock_19070633");
SELECT IS_FREE_LOCK("lock_19070633");
connection default;
SET DEBUG_SYNC= 'now WAIT_FOR parked';
SELECT RELEASE_LOCK("lock_19070633");
RELEASE_LOCK("lock_19070633")
1
# Signaling connection con1 after releasing the lock.
# Without fix, accessing user level lock info in con1 would result in
# crash or valgrind issue invalid read is reported.
SET DEBUG_SYNC= 'now SIGNAL go';
connection con1;
# Reaping: SELECT IS_FREE_LOCK("lock_19070633");
IS_FREE_LOCK("lock_19070633")
0
connection default;
# Verifying issue for IS_USED_LOCK() function.
SELECT GET_LOCK("lock_19070633", 600);
GET_LOCK("lock_19070633", 600)
1
connection con1;
# Waiting after getting user level lock info and releasing mutex.
SET DEBUG_SYNC= 'after_getting_user_level_lock_info SIGNAL parked WAIT_FOR go';
# Sending: SELECT IS_USED_LOCK("lock_19070633");
SELECT IS_USED_LOCK("lock_19070633");
connection default;
SET DEBUG_SYNC= 'now WAIT_FOR parked';
SELECT RELEASE_LOCK("lock_19070633");
RELEASE_LOCK("lock_19070633")
1
# Signaling connection con1 after releasing the lock.
# Without fix, accessing user level lock info in con1 would result in
# crash or valgrind issue invalid read is reported.
SET DEBUG_SYNC= 'now SIGNAL go';
connection con1;
# Reaping: SELECT IS_USED_LOCK("lock_19070633");
IS_USED_LOCK("lock_19070633")
#
connection default;
SET DEBUG_SYNC= 'RESET';
disconnect con1;