verrrry strange:
show create table est_mov_v2:
results:
CREATE TABLE `est_mov_v2` (
`unidade_id` mediumint(8) unsigned NOT NULL DEFAULT '0',
`lote_tipo` enum('v','c','i','tv','tc','ti') NOT NULL DEFAULT 'v',
`lote_spa` decimal(12,1) NOT NULL DEFAULT '0.0',
`item_id` smallint(5) unsigned NOT NULL DEFAULT '0',
`item_id_red` int(11) NOT NULL DEFAULT '0',
`mov_id` char(30) NOT NULL DEFAULT '0',
`oe_tipo` enum('op','oe','tr','ex','bx','bx-tr','rp-tr','custo','conserto') NOT NULL DEFAULT 'oe',
`oe` bigint(20) NOT NULL DEFAULT '0',
`oe_seq` int(11) NOT NULL DEFAULT '0',
`table_partition` tinyint(4) NOT NULL DEFAULT '0',
`lote_data` date NOT NULL DEFAULT '0000-00-00',
`lote` smallint(5) unsigned NOT NULL DEFAULT '0',
`lote_sif_data` date NOT NULL DEFAULT '0000-00-00',
`lote_sif` varchar(8) NOT NULL DEFAULT '0',
`estoque_entrada_proprietario_tipo` enum('f','j') NOT NULL DEFAULT 'f',
`estoque_entrada_proprietario_id` int(11) NOT NULL DEFAULT '0',
`estoque_entrada_pess_tipo` enum('f','j','p') NOT NULL DEFAULT 'f',
`estoque_entrada_pess_id` int(10) unsigned NOT NULL DEFAULT '0',
`estoque_entrada_org` smallint(5) unsigned NOT NULL DEFAULT '0',
`estoque_entrada_org_red` mediumint(9) NOT NULL DEFAULT '0',
`estoque_saida_proprietario_tipo` enum('f','j') NOT NULL DEFAULT 'f',
`estoque_saida_proprietario_id` int(11) NOT NULL DEFAULT '0',
`estoque_saida_pess_tipo` enum('f','j') NOT NULL DEFAULT 'f',
`estoque_saida_pess_id` int(10) unsigned NOT NULL DEFAULT '0',
`estoque_saida_org` smallint(5) unsigned NOT NULL DEFAULT '0',
`estoque_saida_org_red` mediumint(9) NOT NULL DEFAULT '0',
`quant_mov_un` char(5) NOT NULL DEFAULT 'un',
`quant` decimal(17,5) NOT NULL DEFAULT '0.00000',
`pecas` decimal(17,5) NOT NULL DEFAULT '0.00000',
`pbruto` decimal(17,5) NOT NULL DEFAULT '0.00000',
`pliq` decimal(17,5) NOT NULL DEFAULT '0.00000',
`vbruto` decimal(17,5) NOT NULL DEFAULT '0.00000',
`vliq` decimal(17,5) NOT NULL DEFAULT '0.00000',
`data_etiqueta` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`data_producao` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`data_processamento` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`data_validade` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`data_estoque` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`data_estoque_origem` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`data_estoque_destino` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
`destino_confirmado` enum('Y','N') NOT NULL DEFAULT 'Y',
`rastreabilidade_interna` char(25) NOT NULL DEFAULT '',
`rastreabilidade_externa` char(25) NOT NULL DEFAULT '',
`rastreabilidade_pallet` char(25) NOT NULL DEFAULT '',
`externa_tipo` char(25) NOT NULL DEFAULT '',
`valor_bruto_total` decimal(17,5) NOT NULL DEFAULT '0.00000',
`valor_liq_total` decimal(17,5) NOT NULL DEFAULT '0.00000',
`custo_medio_origem` decimal(17,5) NOT NULL DEFAULT '0.00000',
`custo_medio_destino` decimal(17,5) NOT NULL DEFAULT '0.00000',
`custo_patrimonio_origem` decimal(17,5) NOT NULL DEFAULT '0.00000',
`custo_patrimonio_destino` decimal(17,5) NOT NULL DEFAULT '0.00000',
`margem_venda_estimada` decimal(17,5) NOT NULL DEFAULT '0.00000' COMMENT 'para relatorio de venda, custo estimado pode variar no tempo',
`cfop_id` smallint(6) NOT NULL DEFAULT '0',
`cfop_id_red` mediumint(9) NOT NULL DEFAULT '0',
`contrato_producao` char(25) NOT NULL DEFAULT '',
`quant_real` decimal(17,5) NOT NULL DEFAULT '0.00000',
`pecas_real` decimal(17,5) NOT NULL DEFAULT '0.00000',
`pliq_real` decimal(17,5) NOT NULL DEFAULT '0.00000',
`pbruto_real` decimal(17,5) NOT NULL DEFAULT '0.00000',
`vliq_real` decimal(17,5) NOT NULL DEFAULT '0.00000',
`vbruto_real` decimal(17,5) NOT NULL DEFAULT '0.00000',
`usuario` char(25) NOT NULL DEFAULT '',
`sessao` char(41) NOT NULL DEFAULT '',
`lote_rendimento_data` date NOT NULL DEFAULT '0000-00-00',
`lote_rendimento_numero` smallint(5) unsigned NOT NULL DEFAULT '0',
`ponto_movimentacao` mediumint(9) NOT NULL DEFAULT '0',
`rendimento` enum('Y','N') NOT NULL DEFAULT 'N',
`custo_rendimento` enum('Y','N') NOT NULL DEFAULT 'N',
`custo_medio_anterior_rendimento` decimal(17,5) NOT NULL DEFAULT '0.00000' COMMENT 'sempre vai acontecer quando origem=destino',
`custo_patrimonio_anterior_rendimento` decimal(17,5) NOT NULL DEFAULT '0.00000' COMMENT 'sempre vai acontecer quando origem=destino',
`operacao` smallint(5) unsigned NOT NULL DEFAULT '0',
`data_estoque_ts` decimal(21,7) NOT NULL DEFAULT '0.0000000',
`codigo_vinculo_crossdocking` decimal(20,7) unsigned NOT NULL DEFAULT '0.0000000',
`crossdock_unidade_id` int(11) NOT NULL DEFAULT '0',
`crossdock_lote_tipo` enum('v','c','i','tv','tc','ti') NOT NULL DEFAULT 'v',
`crossdock_lote_spa` decimal(12,1) NOT NULL DEFAULT '0.0',
`crossdock_oe` int(11) NOT NULL DEFAULT '0',
`crossdock_oe_seq` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`unidade_id`,`lote_tipo`,`lote_spa`,`item_id`,`item_id_red`,`mov_id`,`oe_tipo`,`oe`,`oe_seq`,`table_partition`)
) ENGINE=Aria DEFAULT CHARSET=latin1
/*!50100 PARTITION BY RANGE (table_partition)
(PARTITION p0 VALUES LESS THAN (1) ENGINE = Aria,
PARTITION p1 VALUES LESS THAN MAXVALUE ENGINE = Aria) */
from error.log:
130609 19:26:09 [ERROR] mysqld got signal 11 ;
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.
To report this bug, see http://kb.askmonty.org/en/reporting-bugs
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.
Server version: 10.0.2-MariaDB-log
key_buffer_size=8388608
read_buffer_size=1048576
max_used_connections=1
max_threads=22
thread_count=1
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 53584 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x0x36719f8
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 = 0x7f0b07971e68 thread_stack 0x48000
mysys/stacktrace.c:247(my_print_stacktrace)[0xa71c9b]
sql/signal_handler.cc:153(handle_fatal_signal)[0x6b1dd8]
:0()[0x7f0b075e81a0]
sequence/sequence.cc:234(ha_seq::open(char const*, int, unsigned int))[0x9247eb]
sql/handler.cc:2380(handler::ha_open(TABLE*, char const*, int, unsigned int))[0x6b59de]
sql/ha_partition.cc:2922(ha_partition::open(char const*, int, unsigned int))[0xa51a37]
sql/handler.cc:2380(handler::ha_open(TABLE*, char const*, int, unsigned int))[0x6b59de]
sql/table.cc:2788(open_table_from_share(THD*, TABLE_SHARE*, char const*, unsigned int, unsigned int, unsigned int, TABLE*, bool))[0x61e35b]
sql/sql_base.cc:3088(open_table(THD*, TABLE_LIST*, st_mem_root*, Open_table_context*))[0x55e381]
sql/sql_base.cc:4405(open_and_process_table)[0x55ee88]
sql/sql_show.cc:1020(mysqld_show_create(THD*, TABLE_LIST*))[0x5e1889]
sql/sql_parse.cc:3141(mysql_execute_command(THD*))[0x593315]
sql/sql_parse.cc:6154(mysql_parse)[0x59810a]
sql/sql_parse.cc:1276(dispatch_command(enum_server_command, THD*, char*, unsigned int))[0x5995ec]
sql/sql_connect.cc:1267(do_handle_one_connection(THD*))[0x63f939]
sql/sql_connect.cc:1183(handle_one_connection)[0x63fa02]
:0()[0x7f0b075e0e0f]
:0()[0x7f0b064c331d]
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (0x7f0ad8004c60): is an invalid pointer
Connection ID (thread ID): 1
Status: NOT_KILLED
Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=off,table_elimination=on,extended_keys=off,exists_to_in=off
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.
Was the table initially created on a 5.x version?
And what moment does the log quote relate to? You didn't mention that the server crashed at any point.
table is 5.5.25 if i'm not wrong, i used 10.0.1 when it was released and after 10.0.2 when it was was released too, so 2 upgrades (5.5.25 -> 10.0.1 -> 10.0.2)
no crash was reported before this MDEV in log no crash too
sorry i read the mdev again, it crashed some minutes before I reported this MDEV when i was executing SELECT * FROM est_mov_v2, after that i tryed DELETE,UPDATE, ALTER, TRUNCATE and it crash too
i don't know the format of frm file.
question:
1)in frm file, it's saved as CONNECT engine?
2) what SHOW CREATE TABLE use to rewrite the CREATE TABLE SQL? it's using the frm file? why it report right ARIA engine, and SHOW TABLE STATUS report CONNECT engine?
to work around the problem
i restarted the server with a version (compiled from source) without_connect_engine, but now it crash with show create table
i get back to 10.0.2 with connect engine, and i could see create table again
i recreated the table, and moved the MAD and MAI files to database again, i repair the table, now it's running again
question:
3)frm file with wrong format could crash server???
Thanks.
So, it indeed seems to be the same problem as MDEV-4466 – your table was also created in a previous version, also an Aria partitioned table initially, which is recognized as some other engine's table.
Why it happens, remains to be figured out.
I'll keep it open for now, till MDEV-4466 is fixed, to check the fix on the attached files.
hi elena i editted the comment, please review if i made something wrong or changed the information about you reply
No, the answer remains the same – it is likely the same problem as in MDEV-4466.
For your questions about how SHOW CREATE TABLE works etc., you can always read the code and find out, it's a benefit of open-source 
i think that's the important part that we could check / maybe develop a tool for it:
1)in frm file, it's saved as CONNECT engine?
a)what is write in file (via notepad or nano or vim)? (there's a tool to check this without mysqld running? something like:
mysqld_read_frm_information frm_file_name.frm
FILE: frm_file_name.frm
FILE FORMAT WITHOUT MYSQLD: (it's a function external of mysqld code, like a external tool)
ENGINE: ARIA PARTITIONED
CREATE TIME: xxxxx
others .frm informations: xxxxx
FILE FORMAT READ BY MYSQLD: (it's the same function of mysqld we are running - 10.0.2 in this case)
ENGINE: CONNECT PARTITIONED
just to help us in debug
maybe we could put it in mariadb.org/file-format.php, where we can send a .frm file (max of 100kb) and get information about it without a mysqld running)
i will create a MDEV for it
2) what SHOW CREATE TABLE use to rewrite the CREATE TABLE SQL?
it's using the frm file information?
why SHOW CREATE TABLE report right ARIA engine, and SHOW TABLE STATUS report CONNECT engine?
they use two different functions?
3)frm file with wrong format could crash server???
that's the main problem, think about a file being copied to mariadb filesystem and it crash the server!
server should mark it as UNKNOWN file format and leave it in filesystem and don't report it as a table
the same happen when a frm file crash (maybe no energy or other problem) and mysqld crash too
MDEV of (1) is MDEV-4637
Fixed along with MDEV-4466