On So, 2008-09-28 at 14:21 +0200, John H. Embretsen wrote:
> Hakan Kuecuekyilmaz wrote:
> > #At file:///home/hakan/work/mysql/mysql-6.0-falcon-team/
> >
> > 2837 Hakan Kuecuekyilmaz 2008-09-28
> > Cleanup.
> > modified:
> > mysql-test/suite/falcon_team/r/falcon_bug_34351_C.result
> > mysql-test/suite/falcon_team/t/falcon_bug_34351_C.test
> > mysql-test/suite/falcon_team/t/test2bug.def
> >
> > per-file messages:
> > mysql-test/suite/falcon_team/r/falcon_bug_34351_C.result
> > Adjusted result file.
> > mysql-test/suite/falcon_team/t/falcon_bug_34351_C.test
> > Removed
> > SELECT count(*) FROM t1;
> > Added missing
> > DROP TABLE t1;
> > mysql-test/suite/falcon_team/t/test2bug.def
> > Added falcon_deadlock to list of
> > known issues.
>
>
> OK to push.
> Still, I hope you will answer one question, below...
>
> > === modified file 'mysql-test/suite/falcon_team/t/test2bug.def'
>
> > +falcon_deadlock: Bug#34182 - SELECT ... FOR UPDATE does not lock when in
> subquery
>
> In Bug#34182 you commented that the bug "blocks" the falcon_deadlock
> test. Can you please be more specific?
> From what I understand, the bug is that a query that should hang does
> not. However, when running the test we get a "Lock wait timeout
> exceeded" error...
You are right. I was only seeing the SELECT ... FOR UPDATE does not lock
when in subquery bug. I have to investige further, why we get the lock
wait timeout.
Good catch,
Hakan
--
Hakan Küçükyılmaz, Senior Software Engineer DBTG/MySQL +49 160
98953296
Sun Microsystems GmbH Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfang Engels, Dr. Roland Boemer
Vorsitz d. Aufs.rat.: Martin Haering HRB MUC 161028 49.011, 8.376
