[MDEV-25996] sux_lock::s_lock(): Assertion !have_s() failed on startup Created: 2021-06-23  Updated: 2021-06-23  Resolved: 2021-06-23

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.6.2
Fix Version/s: 10.6.3

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: debug, regression, rr-profile-analyzed

Issue Links:
Problem/Incident
is caused by MDEV-25743 Unnecessary copying of table names in... Closed

 Description   

In MDEV-25743, the function dict_check_sys_tables() was simplified in such a way that the mini-transaction will not be committed and restarted during the loop. But, we failed to adjust the call that would advance the cursor position:

diff --git a/storage/innobase/dict/dict0load.cc b/storage/innobase/dict/dict0load.cc
index ac81de9a25c..db11f4ff003 100644
--- a/storage/innobase/dict/dict0load.cc
+++ b/storage/innobase/dict/dict0load.cc
@@ -834,7 +834,7 @@ static ulint dict_check_sys_tables()
 
 	for (const rec_t *rec = dict_startscan_system(&pcur, &mtr,
 						      dict_sys.sys_tables);
-	     rec; rec = dict_getnext_system(&pcur, &mtr)) {
+	     rec; rec = dict_getnext_system_low(&pcur, &mtr)) {
 		ulint		len;
 		table_id_t	table_id;
 		ulint		space_id;

It is unclear to me why this would not cause failures much more often. The incorrect call would attempt to restore the persistent cursor position while we are already holding a latch on the page. Recursive S-latches are not supported and could lead to a hang. A hang should however not be possible, because the purge of history is not yet running at this point of time, and no other thread should be acquiring conflicting latches on the page.


Generated at Thu Feb 08 09:41:58 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.