Bug #16175 | memory leak in rpl_trigger.test | ||
---|---|---|---|
Submitted: | 4 Jan 2006 7:43 | Modified: | 2 Mar 2006 15:13 |
Reporter: | Sergei Golubchik | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | 5.0 | OS: | |
Assigned to: | Alexander Ivanov | CPU Architecture: | Any |
[4 Jan 2006 7:43]
Sergei Golubchik
[28 Feb 2006 17:15]
Beat Vontobel
I possibly just ran into this bug: I executed an INSERT INTO a SELECT ... FROM b on the master with a result set of about 22 million rows and a complex trigger on table a. The query took about 47 minutes to execute on the master but everything worked fine. Now on the slave there seems to be a bad memory leak: mysqld slowly eats up more and more memory, starts to swap and finally gets killed by the kernel. Could this be this bug? (I never had similar problems with similar queries without triggers on the target table and never had any problems with inserts of smaller result sets even with triggers.) As the affected system is in full production I'm now mainly concerned to find a quick workaround. But I'll get back to you later. I'd just be happy if you could tell me if this could be the same bug (then I think it should be S1) or I should file another one. Currently running 5.0.18 on both master and slave on Linux.
[1 Mar 2006 10:11]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/3304
[2 Mar 2006 11:53]
Alexander Ivanov
Fixed in 5.0.19
[2 Mar 2006 12:56]
Alexander Ivanov
Fixed in 5.1.8-beta, 5.2.0-alpha
[2 Mar 2006 15:13]
Paul DuBois
Noted in 5.0.19, 5.1.8 changelogs. A memory leak caused warnings on slaves for certain statements that executed without warning on the master. (Bug #16175)