MySQL Forums
Forum List  »  Memory Storage Engine

Hang while executing UPDATE against MEMORY table
Posted by: Simon Gregory
Date: November 28, 2007 03:56AM

I have an UPDATE to a single row in an MEMORY table that has run on average twice per second for 3 months without any problems at all.

Last night the application running it hung while executing it here:

(gdb) thr 10
[Switching to thread 10 (process 1004)]#0 0x007757a2 in _dl_sysinfo_int80 () from /lib/
(gdb) bt
#0 0x007757a2 in _dl_sysinfo_int80 () from /lib/
#1 0x009e95cb in __read_nocancel () from /lib/tls/
#2 0x0017a89f in vio_read () from /usr/lib/
#3 0x0017a91a in vio_read_buff () from /usr/lib/
#4 0x0017bf51 in net_write_command () from /usr/lib/
#5 0x0017c289 in my_net_read () from /usr/lib/
#6 0x00174bdb in cli_safe_read () from /usr/lib/
#7 0x00176435 in mysql_close () from /usr/lib/
#8 0x0017671b in mysql_real_query () from /usr/lib/
#9 0x0014ce88 in mysql_query () from /usr/lib/
#10 0x09097ea8 in ?? ()
#11 0x0000013a in ?? ()
#12 0x0014ce60 in mysql_query () from /usr/lib/
#13 0xb2fc0250 in ?? ()
#14 0xb2fbfa38 in ?? ()
#15 0x0826dc9e in sql_query ()

* My questions really are:

1. has anyone else ever seen anything like this stack trace above?

2. How could a query be related to a mysql_close (is there some autoclose connection done by default at the end of a query I was not aware of?
I cant seem to find any implicit behaviour like that in the 5.0.45 codebase.

3. Could the d/b backing up a seperate InnoDB database at the time this query was executed cause any issues (which it seems not to have done for the last 3 months)?

We are using 5.0.41 Community and the queries executed look like:

UPDATE CachedRSAppliance SET Registered = NOW(), Expires = DATE_ADD(NOW(), INTERVAL 3600 SECOND) WHERE CallingStationId = '01179706575'

i.e. they are pretty simple.

Many thanks for any help / pointers.

Options: ReplyQuote

Written By
Hang while executing UPDATE against MEMORY table
November 28, 2007 03:56AM

Sorry, you can't reply to this topic. It has been closed.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.