CTAS processing can assert with debug build
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
MySQL patches by Codership |
Fix Released
|
Medium
|
Seppo Jaakola | |||
5.5 |
Fix Released
|
Medium
|
Seppo Jaakola | |||
Percona XtraDB Cluster moved to https://jira.percona.com/projects/PXC | Status tracked in 5.6 | |||||
5.5 |
Fix Released
|
Undecided
|
Unassigned | |||
5.6 |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
CREATE TABLE AS SELECT... processing can hit an assert with debug build. The problem happens, if CTAS processing resulted in certification failure during insert...select cycle, and client was OK status was already sent for client before the cert failure was about to be communicated back to client.
Here's the error log:
130330 18:05:05 [Note] WSREP: commit failed for reason: 3
130330 18:05:05 [Note] WSREP: conflict state: 0
130330 18:05:05 [Note] WSREP: cluster conflict due to certification failure for threads:
130330 18:05:05 [Note] WSREP: Victim thread:
THD: 14, mode: local, state: executing, conflict: cert failure, seqno: 124699
SQL: CREATE TABLE x SELECT * FROM `comm00`
mysqld: /home/seppo/
16:05:05 UTC - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
key_buffer_
read_buffer_
max_used_
max_threads=1024
thread_count=14
connection_count=14
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x7feabda5eb60
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7feac0c09e68 thread_stack 0x40000
/home/seppo/
/home/seppo/
/lib/x86_
/lib/x86_
/lib/x86_
/lib/x86_
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/home/seppo/
/lib/x86_
/lib/x86_
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (65f87f0): CREATE TABLE x SELECT * FROM `comm00`
Connection ID (thread ID): 14
Status: NOT_KILLED
Here's stack trace of the asserting thread:
(gdb) bt
#0 __pthread_kill (threadid=
#1 0x00000000008fb531 in my_write_core (sig=6) at /home/seppo/
#2 0x0000000000781ade in handle_fatal_signal (sig=6) at /home/seppo/
#3 <signal handler called>
#4 0x00007feb102f13e5 in __GI_raise (sig=6) at ../nptl/
#5 0x00007feb102f4b4b in __GI_abort () at abort.c:92
#6 0x00007feb102e9d8d in __GI___assert_fail (assertion=0xb38fd8 "! is_set() || can_overwrite_
#7 0x00000000005e0250 in Diagnostics_
#8 0x00000000005cb6b7 in THD::raise_
#9 0x000000000055be82 in my_message_sql (error=1213, str=0x7feac0c06f30 "Deadlock found when trying to get lock; try restarting transaction", MyFlags=0) at /home/seppo/
#10 0x00000000008efa77 in my_error (nr=1213, MyFlags=0) at /home/seppo/
#11 0x0000000000783ec0 in ha_commit_trans (thd=0x7feabda5
#12 0x00000000006fa568 in trans_commit_stmt (thd=0x7feabda5
#13 0x00000000005eedf2 in select_
#14 0x000000000064e588 in do_select (join=0x6a4f6e0, fields=
#15 0x0000000000637531 in JOIN::exec (this=0x6a4f6e0) at /home/seppo/
#16 0x0000000000637d47 in mysql_select (thd=0x7feabda5
#17 0x000000000062fca6 in handle_select (thd=0x7feabda5
#18 0x00000000006007f3 in mysql_execute_
#19 0x000000000060ae51 in mysql_parse (thd=0x7feabda5
#20 0x000000000060a690 in wsrep_mysql_parse (thd=0x7feabda5
#21 0x00000000005fcb84 in dispatch_command (command=COM_QUERY, thd=0x7feabda5eb60, packet=
#22 0x00000000005fba45 in do_command (thd=0x7feabda5
#23 0x00000000006e85d6 in do_handle_
#24 0x00000000006e7ff7 in handle_
#25 0x00007feb10665efc in start_thread (arg=0x7feac0c0
#26 0x00007feb1039ff8d in clone () at ../sysdeps/
#27 0x0000000000000000 in ?? ()
How to reproduce:
This can happen with only one node, running RQG with percona_qa grammar. Here's the command line I used in the test:
perl runall.pl --queries=100000000 --seed=1101 --duration=300 --querytimeout=60 --short_
Related branches
Changed in codership-mysql: | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Seppo Jaakola (seppo-jaakola) |
milestone: | none → 5.5.30-23.7.4 |
Changed in percona-xtradb-cluster: | |
milestone: | none → 5.5.30-23.7.4 |
Changed in percona-xtradb-cluster: | |
status: | New → Fix Released |
Changed in codership-mysql: | |
status: | Fix Released → In Progress |
milestone: | 5.5.31-23.7.5 → 5.6.14-24.1 |
Changed in codership-mysql: | |
status: | Fix Committed → Fix Released |
certification failure was not acknowledged after select..insert phase. Fix for this was pushed in revision: http:// bazaar. launchpad. net/~codership/ codership- mysql/5. 5-23/revision/ 3860