Is buf_LRU_free_page() really supposed to make non-zip block sticky at the end?
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
MySQL Server |
Unknown
|
Unknown
|
|||
Percona Server moved to https://jira.percona.com/projects/PS |
Fix Released
|
Medium
|
Laurynas Biveinis | ||
5.1 |
Invalid
|
Undecided
|
Laurynas Biveinis | ||
5.5 |
Invalid
|
Undecided
|
Laurynas Biveinis | ||
5.6 |
Fix Released
|
Medium
|
Laurynas Biveinis |
Bug Description
Copy of http://
[3 Sep 15:17] Laurynas Biveinis
Description:
buf_LRU_free_page() appears to either have redundant code to needlessly make the removed page sticky to the buffer pool, or at least a misleading comment.
How to repeat:
The relevant bits are:
bool
buf_LRU_
{
...
ut_ad(
...
if (!buf_LRU_
return(true);
}
...
if (b) {
...
} else {
/* There can be multiple threads doing an LRU scan to
free a block. The page_cleaner thread can be doing an
LRU batch whereas user threads can potentially be doing
multiple single page flushes. As we release
buf_pool->mutex below we need to make sure that no one
else considers this block as a victim for page
replacement. This block is already out of page_hash
and we are about to remove it from the LRU list and put
it on the free list. */
mutex_
buf_page_
mutex_
}
buf_pool_
...
}
buf_LRU_
1) The comment "we need sure that no one else considers this block as a victim for page replacement" is false, as the block is not on the LRU list anymore where the victims are picked from;
2) There is no need to make the page sticky here and non-sticky below (not shown in the code snippet).
Suggested fix:
Remove else branch, make the final buf_page_
Related branches
- Alexey Kopytov (community): Approve
- Laurynas Biveinis: Pending requested
-
Diff: 4913 lines (+1001/-789)22 files modifiedPercona-Server/storage/innobase/btr/btr0cur.cc (+18/-6)
Percona-Server/storage/innobase/btr/btr0sea.cc (+5/-8)
Percona-Server/storage/innobase/buf/buf0buddy.cc (+46/-18)
Percona-Server/storage/innobase/buf/buf0buf.cc (+220/-196)
Percona-Server/storage/innobase/buf/buf0dblwr.cc (+1/-0)
Percona-Server/storage/innobase/buf/buf0dump.cc (+8/-8)
Percona-Server/storage/innobase/buf/buf0flu.cc (+153/-125)
Percona-Server/storage/innobase/buf/buf0lru.cc (+280/-177)
Percona-Server/storage/innobase/buf/buf0rea.cc (+41/-26)
Percona-Server/storage/innobase/fsp/fsp0fsp.cc (+1/-1)
Percona-Server/storage/innobase/handler/ha_innodb.cc (+12/-2)
Percona-Server/storage/innobase/handler/i_s.cc (+14/-9)
Percona-Server/storage/innobase/ibuf/ibuf0ibuf.cc (+1/-1)
Percona-Server/storage/innobase/include/buf0buddy.h (+4/-4)
Percona-Server/storage/innobase/include/buf0buddy.ic (+9/-10)
Percona-Server/storage/innobase/include/buf0buf.h (+91/-108)
Percona-Server/storage/innobase/include/buf0buf.ic (+63/-63)
Percona-Server/storage/innobase/include/buf0flu.h (+6/-7)
Percona-Server/storage/innobase/include/buf0flu.ic (+0/-2)
Percona-Server/storage/innobase/include/buf0lru.h (+9/-7)
Percona-Server/storage/innobase/include/sync0sync.h (+13/-4)
Percona-Server/storage/innobase/sync/sync0sync.cc (+6/-7)
tags: | added: innodb |
Percona now uses JIRA for bug reports so this bug report is migrated to: https:/ /jira.percona. com/browse/ PS-1415