MySQL Bugs: #34778: Possible memory leak running UPDATEs in tight loop

Bug #34778	Possible memory leak running UPDATEs in tight loop
Submitted:	23 Feb 2008 18:03	Modified:	9 Oct 2008 11:43
Reporter:	Hakan Küçükyılmaz	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Falcon storage engine	Severity:	S3 (Non-critical)
Version:	6.0.4, mysql-6.0-falcon-team	OS:	Any
Assigned to:	Christopher Powers	CPU Architecture:	Any
Tags:	F_SCAVENGER

Description:
Running falcon_record_cache_memory_leak2-big shows steady increase in Falcon's memory usage.

How to repeat:
Run falcon_record_cache_memory_leak2-big from mysql-6.0-falcon team tree with --big-test option.

./mysql-test-run.pl --big-test --force  --suite=falcon falcon_record_cache_memory_leak2-big

mysqld memory usage starts around 170MB and increases until around 420MB where we get a 

mysqltest: At line 45: query 'UPDATE t1 SET c1 = upper(c1)' failed: 1296: Got error 305 'record memory is exhausted' from Falcon.

Please note that the transaction in the test do not change the rows in question. Every transaction ends in way so that the values are the same as before.

I'm not at all sure this is a bug...  even an update that sets values
to itself does create new record versions.  Until the backlog is in
place, that can fill memory.

We have run this test lot's of times already. The memory consumption got stable after Kevin had fixed couple of memory leaks.

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/44649

ChangeSet@1.2623, 2008-03-30 02:24:29-05:00, cpowers@xeno.mysql.com +8 -0
  Bug#34778, "Possible memory leak running UPDATEs in tight loop"
  
  This test generates thousands of prior record versions for just a
  very few records. The record scavenger ignored the prior record chain
  because the base record was not a scavenge candidate.
  
  The scavenger now scavenges prior records that match the transaction and
  record generation criteria, even when the base record is not scavengable.

Pushed into 6.0.5-alpha

Documented in the 6.0.5 changelog as follows:

        Repeated UPDATE operations on a Falcon table could cause a memory leak.