Hrm, upon further digging it seems that this may be the offending query: # at 416149583 #021107 16:50:31 server id 1 log_pos 416149583 Intvar SET INSERT_ID=6437606; # at 416149611 #021107 16:50:31 server id 1 log_pos 416149583 Query thread_id=19890708 exec_time=0 error_code=0 SET TIMESTAMP=1036716631; INSERT INTO click (offer_id, user_id, points, expected_revenue, actual_revenue, status, interaction_id, category_id, when_clicked, when_updated, manualapproval, isautoimpression, campaign_id, sequence_log_id) VALUES(294, 5729550, 100, 19, NULL, "Clicked", 35, 11, NOW(), NULL, 0, 0, 0, NULL); # at 416149939 #021107 16:50:31 server id 1 log_pos 416149583 Intvar SET INSERT_ID=27770130; # at 416149967 #021107 16:50:31 server id 1 log_pos 416149583 Query thread_id=19890710 exec_time=0 error_
This doesn't appear to be any different than the tens of thousands of other inserts into that table that happen each day... -JF > -----Original Message----- > From: Heikki Tuuri [mailto:Heikki.Tuuri@;innodb.com] > Sent: Friday, November 08, 2002 12:22 AM > To: [EMAIL PROTECTED] > Subject: Re: Replication and temp tables... > > > 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 --------------------------------------------------------------------- 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
