MySQL Bugs: #54965: InnoDB: Warning: purge reached the head of the history list but it is still long

Bug #54965	InnoDB: Warning: purge reached the head of the history list but it is still long
Submitted:	2 Jul 2010 19:01	Modified:	9 Jul 2011 17:10
Reporter:	Mikhail Izioumtchenko	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: InnoDB Plugin storage engine	Severity:	S3 (Non-critical)
Version:	5.1, mysql-trunk-innodb	OS:	Any
Assigned to:	Sunny Bains	CPU Architecture:	Any
Triage:	Needs Triage: D4 (Minor)

Description:
after crash recovery I see the following in the error log:

InnoDB: Apply batch completed
InnoDB: Starting in background the rollback of uncommitted transactions
100702 11:13:50  InnoDB: Rolling back trx with id EB2E9, 1 rows to undo
100702 11:13:50 InnoDB 1.1.1 started; log sequence number 8401800967
100702 11:13:50  InnoDB: Warning: purge reached the head of the history list,
InnoDB: but its length is still reported as 56521! Make a detailed bug
InnoDB: report, and submit it to http://bugs.mysql.com

in another example I have the history list length is about 180K

After that everything seems to work fine, though, and the history
list length recedes close to 0 with time if there is no other activity.

It looks that if mysqld is
killed when the history length is long, we are likely to see this message
soon after recovery.

How to repeat:
not 100% but I got messages like above 2 out of 3 times

1. start mysqld with very large buffer pool and redo logs, 28g and 2047m
in my case.
2. use sysbench table that fits in the buffer pool, I tried 1m and 25m rows.
4. sysbench readwrite, 4 threads, 60 seconds. It happened to be important to start
with this.
5. start sysbench readwrite, 64 threads, 600 seconds
6. wait 300 seconds and kill -9 mysqld

after recovery there are history list warnings in the error log, repeatable
every time for the dataset.

triage: setting tag to  SRMRTBD (can be fixed but not required for GA as been there for a long time)

likely a duplicate of bug#31123.

Mark it as a duplicate of bug#31123.

Could we re-triage this?  Since this requires a full tablespace recreation, it seems like more than a D4.
It's affected several customers too.

The bug that this one was set as a duplicate of was closed, as bug reporter there found corruption of InnoDB files. Here this is not the case, as far as I understand, so I set this back to 'Verified".

Bug #44923 was marked as a duplicate of this one.