Jon, ----- Original Message ----- From: ""Jon Frisby"" <[EMAIL PROTECTED]> Newsgroups: mailing.database.mysql Sent: Thursday, November 07, 2002 9:39 PM Subject: Replication and temp tables...
> Using 4.0.2 for both server and client, replicating the following query > seems to have caused a crash on the client: > > CREATE TEMPORARY TABLE tmp1 ( > day DATE NOT NULL, > campaign_id INT NOT NULL, > > clicks INT, > clicked FLOAT, > approved FLOAT, > users_raw INT, > users_coreg INT, > users_fullreg INT, > visitors INT, > > PRIMARY KEY (day, campaign_id) > ) TYPE=InnoDB; > > > The error log (w/ symbols resolved) is: > > 021107 8:51:32 Slave SQL thread initialized, starting replication in > log 'db1-bin.085' at position 113214771, relay log './db3-relay-bin.001' > position: 25762057 > 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. > 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_size=268431360 > record_buffer=2093056 > sort_buffer=1048568 > max_used_connections=0 > max_connections=50 > threads_connected=1 > It is possible that mysqld could use up to > key_buffer_size + (record_buffer + sort_buffer)*max_connections = 415539 > K > bytes of memory > Hope that's ok; if not, decrease some variables in the equation. > > thd=0x85261b0 > 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... > Cannot determine thread, fp=0xbfe3f248, backtrace may not be correct. > Stack range sanity check OK, backtrace follows: > 0x80722d8 init_signals__Fv + 16 > 0x82de908 _end + 239148 > 0x82cb534 _end + 160344 > 0x80e9a58 register_slave__FP3THDPUcUi + 228 > 0x80af595 exec_event__21Create_file_log_eventP17st_relay_log_info + 537 > 0x80b04f4 __15Query_log_eventP3THDPCcb + 160 > 0x80ebf71 nisam_open + 1837 > 0x80ece8f _nisam_search + 79 > 0x82dbf1c _end + 228416 > 0x831193a _end + 448094 > New value of fp=(nil) failed sanity check, terminating stack trace! > Please read http://www.mysql.com/doc/U/s/Using_stack_trace.html and > follow instructions on how to resolve the stack trace. Resolved > stack trace is much more helpful in diagnosing the problem, so please do > > resolve it > Trying to get some variables. > Some pointers may be invalid and cause the dump to abort... > thd->query at (nil) is invalid pointer > thd->thread_id=3 > > > Any ideas on what might be causing this? using a temporary InnoDB table inside LOCK TABLES caused an assertion failure in versions < 4.0.4. But I do not see how the slave would use it inside LOCK TABLES, and there is no assertion printout either. There have been quite a lot of bug fixes since July 10, when 4.0.2 was released. Some of them might fix the problem. Can you repeat the crash if you manually create temporary tables on the master? > -JF Best regards, Heikki Tuuri Innobase Oy --- InnoDB - transactions, hot backup, and foreign key support for MySQL See http://www.innodb.com, download MySQL-Max from http://www.mysql.com sql query --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
