transaction started in ::store_lock() and not by startStatement/Transaction

Bug #535528 reported by Stewart Smith
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Drizzle
Triaged
Medium
Andrew Hutchings
7.0
Won't Fix
Medium
Andrew Hutchings
Cherry
Fix Released
High
Jay Pipes

Bug Description

For the following sequence:

create table t1 (a int, b int not null, c int null, d int not null);
show create table t1;
insert into t1 values (0,0, 0, 0);

when HTON_SKIP_STORE_LOCK is set for the engine and with autocommit on, we get no call to startTransaction or startStatement.

If HTON_SKIP_STORE_LOCK is *NOT* set, then (at least) innobase sets up the transaction (check_trx_exists()) in ::store_lock call in the mysql_lock_tables (for mysql_insert()).

backtrace:
#0 check_trx_exists (session=0xa21f00)
    at plugin/innobase/handler/ha_innodb.cc:1423
#1 0x00007ffff496f8b9 in ha_innobase::store_lock (this=0x1230968,
    session=0xa21f00, to=0x1231d98,
    lock_type=drizzled::TL_WRITE_CONCURRENT_INSERT)
    at plugin/innobase/handler/ha_innodb.cc:7500
#2 0x00000000004d3064 in get_lock_data (session=0xa21f00,
    table_ptr=0x1224bc8, count=1, should_lock=true,
    write_lock_used=0x7fffe4ddfab8) at drizzled/lock.cc:626
#3 0x00000000004d20e7 in drizzled::mysql_lock_tables (session=0xa21f00,
    tables=0x1224bc8, count=1, flags=4, need_reopen=0x7fffe4ddfb7f)
    at drizzled/lock.cc:189
#4 0x0000000000551e98 in drizzled::Session::lock_tables (this=0xa21f00,
    tables=0x1224818, count=1, need_reopen=0x7fffe4ddfb7f)
    at drizzled/sql_base.cc:2196
#5 0x000000000053d9e8 in drizzled::Session::openTablesLock (this=0xa21f00,
    tables=0x1224818) at drizzled/session.cc:2016
#6 0x000000000055b77d in drizzled::mysql_insert (session=0xa21f00,
    table_list=0x1224818, fields=..., values_list=..., update_fields=...,
    update_values=..., duplic=drizzled::DUP_ERROR, ignore=false)
    at drizzled/sql_insert.cc:250

interestingly enough though... we do seem to get a commit():

#0 innobase_commit_low (trx=0x1230e00)
    at plugin/innobase/handler/ha_innodb.cc:2050
#1 0x00007ffff4966e9e in InnobaseEngine::doCommit (this=0xa36010,
    session=0xa21f00, all=false) at plugin/innobase/handler/ha_innodb.cc:2175
#2 0x00000000005da7a4 in drizzled::plugin::TransactionalStorageEngine::commit
    (this=0xa36010, session=0xa21f00, normal_transaction=false)
    at ./drizzled/plugin/transactional_storage_engine.h:84
#3 0x00000000005d9499 in drizzled::TransactionServices::ha_commit_one_phase (
    this=0x9de6d8, session=0xa21f00, normal_transaction=false)
    at drizzled/transaction_services.cc:594
#4 0x00000000005d937d in drizzled::TransactionServices::ha_commit_trans (
    this=0x9de6d8, session=0xa21f00, normal_transaction=false)
    at drizzled/transaction_services.cc:564
#5 0x00000000005d989a in drizzled::TransactionServices::ha_autocommit_or_rollback (this=0x9de6d8, session=0xa21f00, error=0)
    at drizzled/transaction_services.cc:715
#6 0x000000000056b5c6 in drizzled::dispatch_command (
    command=drizzled::COM_QUERY, session=0xa21f00,
    packet=0x1226841 "insert into t1 values (0,0, 0, 0)", packet_length=33)
    at drizzled/sql_parse.cc:246

Related branches

Revision history for this message
Stewart Smith (stewart) wrote :

Jay, I assigned this to you as you've been playing around with that code recently and may be able to resolve it a bit quicker than me... although I'm happy to take it if wanted (but will be a little while before I get to it).

Revision history for this message
Jay Pipes (jaypipes) wrote :

No prob, Stew. It needs to be fixed, and this is just one symptom of the asinine PSEAPI. Thanks for the bug report.

Changed in drizzle:
importance: Low → High
milestone: none → 2010-03-29
Revision history for this message
Jay Pipes (jaypipes) wrote :

Should be fixes in lp:~jaypipes/drizzle/bug534806.

Please merge that branch in and test if that fixes this bug as well.

Thanks!

Jay

Changed in drizzle:
status: Confirmed → In Progress
Jay Pipes (jaypipes)
Changed in drizzle:
status: In Progress → Fix Released
Revision history for this message
Stewart Smith (stewart) wrote :
Download full text (3.2 KiB)

The following patch will hit the assert when running the embedded_innodb test suite

=== modified file 'plugin/embedded_innodb/embedded_innodb_engine.cc'
--- plugin/embedded_innodb/embedded_innodb_engine.cc 2010-09-27 09:04:26 +0000
+++ plugin/embedded_innodb/embedded_innodb_engine.cc 2010-09-28 05:40:05 +0000
@@ -617,20 +617,7 @@ THR_LOCK_DATA **EmbeddedInnoDBCursor::st
                                                  THR_LOCK_DATA **to,
                                                  thr_lock_type lock_type)
 {
- /* Currently, we can get a transaction start by ::store_lock
- instead of beginTransaction, startStatement.
-
- See https://bugs.launchpad.net/drizzle/+bug/535528
-
- all stemming from the transactional engine interface needing
- a severe amount of immodium.
- */
-
- if(*get_trx(session) == NULL)
- {
- static_cast<EmbeddedInnoDBEngine*>(getEngine())->
- doStartTransaction(session, START_TRANS_NO_OPTIONS);
- }
+ assert((*get_trx(session)) != NULL);

#2 0x00007ffff52bc941 in *__GI___assert_fail (
    assertion=0x7ffff27ae746 "(*get_trx(session)) != __null",
    file=<value optimized out>, line=620,
    function=0x7ffff27b0f00 "virtual drizzled::THR_LOCK_DATA** EmbeddedInnoDBCursor::store_lock(drizzled::Session*, drizzled::THR_LOCK_DATA**, drizzled::thr_lock_type)") at assert.c:81
#3 0x00007ffff278db11 in EmbeddedInnoDBCursor::store_lock (this=0x183e1b0,
    session=0x1836f20, to=0x183edc8,
    lock_type=drizzled::TL_WRITE_CONCURRENT_INSERT)
    at plugin/embedded_innodb/embedded_innodb_engine.cc:620
#4 0x00000000007075c5 in get_lock_data (session=0x1836f20,
    table_ptr=0x183c7c0, count=1, should_lock=true,
    write_lock_used=0x7fffdef91728) at drizzled/lock.cc:631
#5 0x000000000070661f in drizzled::mysql_lock_tables (session=0x1836f20,
    tables=0x183c7c0, count=1, flags=4, need_reopen=0x7fffdef917ef)
    at drizzled/lock.cc:193
#6 0x000000000079d342 in drizzled::Session::lock_tables (this=0x1836f20,
    tables=0x183c228, count=1, need_reopen=0x7fffdef917ef)
    at drizzled/sql_base.cc:2307
#7 0x000000000078355c in drizzled::Session::openTablesLock (this=0x1836f20,
---Type <return> to continue, or q <return> to quit---
    tables=0x183c228) at drizzled/session.cc:1889
#8 0x00000000007aafc7 in drizzled::mysql_insert (session=0x1836f20,
    table_list=0x183c228, fields=..., values_list=..., update_fields=...,
    update_values=..., duplic=drizzled::DUP_ERROR, ignore=false)
    at drizzled/sql_insert.cc:258
#9 0x000000000080ad65 in drizzled::statement::Insert::execute (this=0x1851e30)
    at drizzled/statement/insert.cc:57
#10 0x00000000007bc762 in mysql_execute_command (session=0x1836f20)
    at drizzled/sql_parse.cc:479
#11 0x00000000007bd524 in drizzled::mysql_parse (session=0x1836f20,
    inBuf=0x18327b8 "INSERT INTO t1 VALUES ('40004712','000001','0010',9)",
    length=52) at drizzled/sql_parse.cc:750
#12 0x00000000007bc0b6 in drizzled::dispatch_command (
    command=drizzled::COM_QUERY, session=0x1836f20,
    packet=0x1832f11 "INSERT INTO t1 VALUES ('40004712','000001','0010',9)",
    packet_length=52) at drizzled/sql_parse.cc:224
#13 0x000000000077e82d in ...

Read more...

Revision history for this message
David Shrewsbury (dshrews) wrote :

Don't believe this was meant to be assigned to me.

Changed in drizzle:
assignee: David Shrewsbury (dshrews) → Stewart Smith (stewart)
Stewart Smith (stewart)
Changed in drizzle:
milestone: 2010-10-11 → none
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.