[MDEV-33208] InnoDB: Trying to access update undo rec field 50 in index `PRIMARY` of table NNN but index has only 14 fields Created: 2024-01-10 Updated: 2024-01-18 |
|
| Status: | Needs Feedback |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB |
| Affects Version/s: | 10.11.6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major |
| Reporter: | Alex | Assignee: | Marko Mäkelä |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Linux firefly 4.19.0-25-amd64 #1 SMP Debian 4.19.289-2 (2023-08-08) x86_64 GNU/Linux |
||
| Issue Links: |
|
||||||||
| Description |
|
Hit this error: 2024-01-09 20:15:31 0 [ERROR] InnoDB: Trying to access update undo rec field 50 in index `PRIMARY` of table `meshok`.`btc_invoice` but index has only 14 fields Submit a detailed bug report to https://jira.mariadb.org/. Run also CHECK TABLE `meshok`.`btc_invoice`. n_fields = 44, i = 0 Your assistance in bug reporting will enable us to fix this for the next release. We will try our best to scrape up some info that will hopefully help Server version: 10.11.6-MariaDB-1:10.11.6+maria~deb10-log source revision: fecd78b83785d5ae96f2c6ff340375be803cd299 Thread pointer: 0x560e3e1e4ec8 Optimizer switch: index_merge=on,index_merge_union=on,index_merge_sort_union=on,index_merge_intersection=on,index_merge_sort_intersection=off,engine_condition_pushdown=off,index_condition_pushdown=on,derived_merge=on,derived_with_keys=on,firstmatch=on,loosescan=on,materialization=on,in_to_exists=on,semijoin=on,partial_match_rowid_merge=on,partial_match_table_scan=on,subquery_cache=on,mrr=off,mrr_cost_based=off,mrr_sort_keys=off,outer_join_with_cache=on,semijoin_with_cache=on,join_cache_incremental=on,join_cache_hashed=on,join_cache_bka=on,optimize_join_buffer_size=on,table_elimination=on,extended_keys=on,exists_to_in=on,orderby_uses_equalities=on,condition_pushdown_for_derived=on,split_materialized=on,condition_pushdown_for_subquery=on,rowid_filter=on,condition_pushdown_from_having=on,not_null_range_scan=off,hash_join_cardinality=off,cset_narrowing=off The manual page at https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ contains We think the query pointer is invalid, but we will try to print it anyway. Writing a core file... Kernel version: Linux version 4.19.0-25-amd64 (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.289-2 (2023-08-08) |
| Comments |
| Comment by Marko Mäkelä [ 2024-01-10 ] |
|
Can you please post a full stack trace on the crash, as instructed by https://mariadb.com/kb/en/how-to-produce-a-full-stack-trace-for-mariadbd/ (which was included in the error log excerpt that you posted)? Based on the incompletely resolved stack trace, it looks like InnoDB is crashing either while rolling back an incomplete transaction, or while purging the history of some committed transactions. This crash should be removed (it was missed in Does the server start up if you set innodb_force_recovery=2 or 3? |
| Comment by Alex [ 2024-01-13 ] |
|
innodb_force_recovery=2 helped |
| Comment by Alex [ 2024-01-15 ] |
|
Downgrade to 10.11.4 fixes the problem |
| Comment by Marko Mäkelä [ 2024-01-15 ] |
|
Can you provide the requested details about the crash? I don’t think that much changed between 10.11 and 11.0 with regard to undo logs. |
| Comment by Alex [ 2024-01-15 ] |
|
Too complicated for me. Will observe 10.11.4. Will it happen again or not. |
| Comment by Jonas Liljestrand [ 2024-01-16 ] |
|
I'm currenty planing on upgrading to MariaDB 10.11.6 and while preparing for that I found this issue (here) and want to know more about it before going live. Alex may I ask you for details on why you decided to downgrade to 10.11.4? |
| Comment by Alex [ 2024-01-16 ] |
|
@jonlil , Well, the problem appear after I upgraded from 10.11.4 to 10.11.6. That is why I downgraded. Will observe. |
| Comment by Marko Mäkelä [ 2024-01-16 ] |
|
10.11.6 fixes some corruption bugs that affect 10.11.4, such as This bug might share a root cause with MDEV-33189, which is equally hard to reproduce. If that is the case, the bug would have been introduced already by |
| Comment by Marko Mäkelä [ 2024-01-17 ] |
|
If my hypothesis in MDEV-33189 is correct, this corruption could be prevented by setting innodb_adaptive_flushing=OFF. Can anyone try that? |