11 messages in com.mysql.lists.bugsRe: I got it hanged !| From | Sent On | Attachments |
|---|---|---|
| Peter Zaitsev | 16 Jul 2001 08:09 | |
| Heikki Tuuri | 16 Jul 2001 09:01 | |
| Michael Widenius | 16 Jul 2001 18:07 | |
| Jamie Mason | 16 Jul 2001 20:39 | |
| Peter Zaitsev | 17 Jul 2001 02:14 | |
| Michael Widenius | 17 Jul 2001 02:30 | |
| Peter Zaitsev | 17 Jul 2001 02:44 | |
| Peter Zaitsev | 17 Jul 2001 03:59 | |
| Michael Widenius | 17 Jul 2001 11:15 | |
| Peter Zaitsev | 18 Jul 2001 00:08 | |
| Michael Widenius | 18 Jul 2001 00:18 |
| Subject: | Re: I got it hanged ! |
|---|---|
| From: | Michael Widenius (mon...@mysql.com) |
| Date: | 07/16/2001 06:07:27 PM |
| List: | com.mysql.lists.bugs |
Hi!
"Heikki" == Heikki Tuuri <Heik...@innodb.com> writes:
Heikki> Hi! Heikki> This may be a bug in the MySQL part of the code. Heikki> It looks like in sql_base.cc the pthread mutex LOCK_open Heikki> has been locked but not released by some thread. Heikki> Is it so that the ALTER TABLE went through without Heikki> hanging?
Heikki> It is crucial to know if all interesting threads are stuck waiting Heikki> for the LOCK_open mutex, or if some thread is stuck inside InnoDB Heikki> code. Did you look carefully through all the threads printing bt?
Heikki> In the processlist one thread is 'copying to tmp table'. What does bt
say
Heikki> for that thread?
Just that it MySQL needs to create a temporary table to resolve the query. This should not have anything to do with this, as temporary tables doesn't have to do locks during open.
Heikki> Anyway, to find out who failed to release the mutex we should
Heikki> compile in debug code which would tell who locked LOCK_open,
Heikki> and in which query. You could add a global char* variable in sql_base.cc
Heikki> and store about on line 781 table_name to it when it reserves LOCK_open.
Heikki> Now, if mysqld hangs, you can with gdb print the value of the global
Heikki> variable
Heikki> and you see what table was accessed when the pthread mutex was
Heikki> locked. I think thd (user session object) does not contain the query
Heikki> text as a string. It would be nice if it contained it and one could
store
Heikki> the
Heikki> query text to the global variable.
To just compile MySQL with --with-debug=full, should in most cases be enough to find conflicting mutexes.
You can find the current query in 'thd->query'
Heikki> Monty, can you advise Peter about this?
Heikki> By the way, why do you need to ALTER a table which is simultaneously
Heikki> used in queries? Why do you use LOCK TABLES when you dump a table?
Heikki> In InnoDB you can just SELECT INTO OUTFILE, since InnoDB does a
Heikki> consistent read by default. If you do several SELECT INTO OUTFILEs in
the
Heikki> same transaction you can dump several tables seen at the same snapshot
Heikki> of the database.
mysql 3.23.39 Linux Innodb.
I've got INNODB to hang quite simple way - I just run an alter table on a table which was used in many queries. I run "alter table table_groups add version int unsigned not null"
I got mysql to be completely stock with the following result:
1) PROCESSLIST:
As you see all queries got stuck it "opening tables" or "closing tables"
<cut>
I am now home for a couple of days, but I don't think I will have time to resolve this during this time, if no one manages to write a test case that shows this problem :(
Peter, is the symptom that ALTER TABLE works and completes but you get a hang after this, or is the problem that ALTER TABLE doesn't work.
Regards, Monty