Skip to content

go/store/nbs: Fix a race between the journal persister and PruneTableFiles. - #11312

Merged
reltuk merged 3 commits into
mainfrom
aaron/gc-panic-on-shutdown
Jul 17, 2026
Merged

go/store/nbs: Fix a race between the journal persister and PruneTableFiles.#11312
reltuk merged 3 commits into
mainfrom
aaron/gc-panic-on-shutdown

Conversation

@reltuk

@reltuk reltuk commented Jul 16, 2026

Copy link
Copy Markdown
Contributor

When PruneTableFiles runs, it is willing to delete the journal file if there is no longer a reference to it in the manifest. This can race with bootstrapJournal making a new journal file. The journal file can be on disk, and seen by PruneTableFiles and thus selected for removal, before the journal has been added to the chunk store proper.

This change makes the journal writer participate in the retained files machinery, same as the table file persister, so that the journal is correctly considered not-safe-for-delete-by-PruneTableFiles before it is ever created on disk and potentially selected for deletion by PruneTableFiles.

…Files. Racing GC and/or crashing at an inopportune time could result in "root hash not found" or a panic on attempting to remove a missing journal file.
@reltuk
reltuk requested a review from nicktobey July 16, 2026 22:05
@coffeegoddd

Copy link
Copy Markdown
Contributor

@reltuk DOLT

comparing_percentages
100.000000 to 100.000000
version result total
a287668 ok 5937471
version total_tests
a287668 5937471
correctness_percentage
100.0

@coffeegoddd

coffeegoddd commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

@reltuk DOLT

read_tests from_latency to_latency percent_change
covering_index_scan 2.3 2.3 0.0
groupby_scan 147.61 150.29 1.82
index_join 1.93 1.93 0.0
index_join_scan 1.32 1.32 0.0
index_scan 219.36 223.34 1.81
oltp_point_select 0.25 0.25 0.0
oltp_read_only 5.0 5.0 0.0
select_random_points 0.51 0.51 0.0
select_random_ranges 0.65 0.64 -1.54
table_scan 200.47 204.11 1.82
types_table_scan 467.3 458.96 -1.78
write_tests from_latency to_latency percent_change
oltp_delete_insert 6.09 6.21 1.97
oltp_insert 3.13 3.13 0.0
oltp_read_write 11.24 11.24 0.0
oltp_update_index 3.3 3.3 0.0
oltp_update_non_index 3.02 3.02 0.0
oltp_write_only 6.32 6.32 0.0
types_delete_insert 6.79 6.79 0.0

@coffeegoddd

Copy link
Copy Markdown
Contributor

@reltuk DOLT

comparing_percentages
100.000000 to 100.000000
version result total
23b961d ok 5937471
version total_tests
23b961d 5937471
correctness_percentage
100.0

@coffeegoddd

coffeegoddd commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

@reltuk DOLT

test_name from_latency_p95 to_latency_p95 percent_change
tpcc-scale-factor-1 45.79 46.63 1.83
test_name from_server_name from_server_version from_tps to_server_name to_server_version to_tps percent_change
tpcc-scale-factor-1 dolt 49b81b6 52.71 dolt b9d9a6b 52.42 -0.55

…ve this test case test running SIGKILL against the process as well.
@coffeegoddd

Copy link
Copy Markdown
Contributor

@reltuk DOLT

comparing_percentages
100.000000 to 100.000000
version result total
b9d9a6b ok 5937471
version total_tests
b9d9a6b 5937471
correctness_percentage
100.0

@nicktobey

Copy link
Copy Markdown
Contributor

Could you add a more detailed description to the PR, explaining why the race necessitates the creating the concept of a "protected journal file", and outlining a sequence of events that previously would have resulted in data corruption and why it wouldn't happen under the new PR?

// the NomsBlockStore mutex, while PruneTableFiles runs under the persister's
// pruneMu; before the fix these disjoint lock domains let a prune delete a live
// journal file, and left ChunkJournal.PruneTableFiles reading j.wr without
// synchronization. Run under `-race` this reliably catches the unsynchronized

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this reliably catches the race condition as the comment says, why does it run 300 iterations? Do we use a "race" flag in our tests?

@reltuk
reltuk merged commit b130ee8 into main Jul 17, 2026
31 of 33 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants