Hi Kentoku, I'm adding MariaDB developers to CC. On Thu, Sep 19, 2013 at 01:19:13AM +0900, kentoku wrote:
Hi Sergey,
But what kind of errors are possible in your case? Other storage engines doesn't seem to suffer from this API violation.
Spider support bulk updating and deleting for avoiding network roundtrip between data node. Some times, last bulk updating is executed in rnd_end() function. So rnd_end() has possibility getting errors from data node. I'm afraid fixing rnd_end() callers in the server may stall for a long time. Is it accaptable for spider to use bulk updates and deletes API instead (see handler.h: start_bulk_update/start_bulk_delete).
By the way, about MDEV-4739. I get the following stack trace. Program received signal SIGSEGV, Segmentation fault. 0x00000000005eabf6 in thd_wait_begin (thd=0x29da060, wait_type=10) at /ssd1/mariadb-10.0.4/sql/sql_class.cc:4277 4277 MYSQL_CALLBACK(thd->scheduler, thd_wait_begin, (thd, wait_type)); (gdb) print thd $1 = (THD *) 0x29da060 (gdb) bt #0 0x00000000005eabf6 in thd_wait_begin ( thd=0x29da060, wait_type=10) at /ssd1/mariadb-10.0.4/sql/sql_class.cc:4277 #1 0x000000000072a114 in scheduler_wait_sync_begin () at /ssd1/mariadb-10.0.4/sql/scheduler.cc:59 #2 0x0000000000d6dc20 in my_sync (fd=23, my_flags=0) at /ssd1/mariadb-10.0.4/mysys/my_sync.c:76 #3 0x0000000000d6b54f in my_msync (fd=23, addr=0x7ffff7ff4000, len=4096, flags=4) at /ssd1/mariadb-10.0.4/mysys/my_mmap.c:27 #4 0x00000000008bea03 in TC_LOG_MMAP::open ( this=0x16e6a00, opt_name=0xe19c87 "tc.log") at /ssd1/mariadb-10.0.4/sql/log.cc:7735 #5 0x00000000005751cb in init_server_components () at /ssd1/mariadb-10.0.4/sql/mysqld.cc:4797 #6 0x0000000000575a07 in mysqld_main (argc=30, argv=0x1f204d0) at /ssd1/mariadb-10.0.4/sql/mysqld.cc:5208 #7 0x000000000056d884 in main (argc=11, argv=0x7fffffffe3a8) at /ssd1/mariadb-10.0.4/sql/main.cc:25 (gdb) print thd->scheduler $2 = (scheduler_functions *) 0x8f8f8f8f8f8f8f8f (gdb) print thd_wait_begin $3 = {void (THD *, int)} 0x5eaba4 <thd_wait_begin(THD*, int)> (gdb) print wait_type $4 = 10
It is looks that "thd->scheduler" is not initialized. What do you think? Must storage engine set it? Nope, it looks like a bug in thread pool. MDEV-4739 has different trace, how did you get this one? Just executed given test?
Regards, Sergey