core/rawdb: allow head truncation below the tail of a newly aligned table - #35536
core/rawdb: allow head truncation below the tail of a newly aligned table#355360xSHKWON wants to merge 1 commit into
Conversation
|
Have you ever experienced with this symptom? Or it's just simulated by AI |
|
Not on a live node, I found it while reading the #35258 carve-out. But it’s mechanically reproducible: revert the |
| if existing == hidden { | ||
| // Empty table means that it is newly added. Its tail would be | ||
| // at the head, so we have to align the table down to the new head. | ||
| // A table whose tail sits exactly at its first stored item has never had |
There was a problem hiding this comment.
I don't think this fix is correct.
The actual issue is that the BAL table is initialized at the common head of the tables, with everything below it already pruned. If the freezer later needs to be truncated below that common head, there is simply nothing left to delete.
This is a very specific upgrade-path issue, and we don't want to make "truncate below tail" a generally valid operation.
existing == hidden is intended to identify empty tables. We shouldn't broaden that condition to cover additional cases.
There was a problem hiding this comment.
EDIT:
We should allow "truncate below tail" becomes valid across the different group. Let me figure out the better solution.
2 participants
The #35258 carve-out only holds while the new table is still empty, and bals stops being empty after the first frozen block. From then on a rewind below the alignment point fails with “truncation below tail” (the symptom of #35210), headerchain escalates it to log.Crit, and with the other tables already truncated, the freezer no longer opens on the next start.
Key the relaxation on the tail sitting at the table’s first stored item instead: an aligned table keeps that property for life, while a tail that has moved past it has genuinely pruned data below and is still rejected.