1berry/MariaDB-server
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove a stale comment

Browse Source 
buf_LRU_block_remove_hashed(): Remove a comment that had been added
in mysql/mysql-server@aad1c7d0dd
and apparently referring to buf_LRU_invalidate_tablespace(),
which was later replaced with buf_LRU_flush_or_remove_pages() and
ultimately with buf_flush_remove_pages() and buf_flush_list_space().
All that code is covered by buf_pool.mutex. The note about releasing
the hash_lock for the buf_pool.page_hash slice would actually apply to
the last reference to hash_lock in buf_LRU_free_page(), for the
case zip=false (retaining a ROW_FORMAT=COMPRESSED page while
discarding the uncompressed one).
This commit is contained in:
Marko Mäkelä 2023-08-21 13:28:12 +03:00
parent 5895a3622b
commit be5fd3ec35
1 changed files with 0 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
storage/innobase/buf/buf0lru.cc
View File

@ -1186,25 +1186,6 @@ static bool buf_LRU_block_remove_hashed(buf_page_t *bpage, const page_id_t id,
return true;
}
/* Question: If we release hash_lock here
then what protects us against:
1) Some other thread buffer fixing this page
2) Some other thread trying to read this page and
not finding it in buffer pool attempting to read it
from the disk.
Answer:
1) Cannot happen because the page is no longer in the
page_hash. Only possibility is when while invalidating
a tablespace we buffer fix the prev_page in LRU to
avoid relocation during the scan. But that is not
possible because we are holding buf_pool mutex.
2) Not possible because in buf_page_init_for_read()
we do a look up of page_hash while holding buf_pool
mutex and since we are holding buf_pool mutex here
and by the time we'll release it in the caller we'd
have inserted the compressed only descriptor in the
page_hash. */
hash_lock->write_unlock();
if (bpage->zip.data) {