maria-developers team mailing list archive

[Sergey Vojtovich <svoj@xxxxxxxxxxx>]

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