Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use delete_range instead of clear() to avoid race condition #12855

Merged
merged 1 commit into from
Jul 6, 2023

Conversation

mystenmark
Copy link
Contributor

because clear() drops and re-creates the table without holding a lock, it can cause crashes if other threads happen to try to write to or read from the table being cleared. I don't think it makes sense to add locking to every DBMap access just to fix this case, so I'm just going to avoid calling clear().

@mystenmark mystenmark requested a review from williampsmith July 6, 2023 02:30
@vercel
Copy link

vercel bot commented Jul 6, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

6 Ignored Deployments
Name Status Preview Updated (UTC)
explorer ⬜️ Ignored (Inspect) Jul 6, 2023 2:30am
explorer-storybook ⬜️ Ignored (Inspect) Jul 6, 2023 2:30am
multisig-toolkit ⬜️ Ignored (Inspect) Jul 6, 2023 2:30am
sui-kiosk ⬜️ Ignored (Inspect) Jul 6, 2023 2:30am
sui-wallet-kit ⬜️ Ignored (Inspect) Jul 6, 2023 2:30am
wallet-adapter ⬜️ Ignored (Inspect) Jul 6, 2023 2:30am

@mystenmark mystenmark requested a review from sadhansood July 6, 2023 02:30
.next()
{
let mut batch = self.locally_computed_checkpoints.batch();
batch.delete_range(&self.locally_computed_checkpoints, &0, &last_local_summary)?;
Copy link
Contributor

Choose a reason for hiding this comment

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

This makes sense, we also have ignore_range_delete set to true by default, so we shouldn't see any performance impact on the read side from it.

@mystenmark mystenmark merged commit 199e0b0 into main Jul 6, 2023
@mystenmark mystenmark deleted the mlogan-fix-ckpt-prune branch July 6, 2023 02:58
@lxfind
Copy link
Contributor

lxfind commented Jul 6, 2023

Ah interesting.
Could we follow up and maybe rename current clear to unsafe_clear and then add a safe version of clear? (and document well)
Because I would totally make the same mistake if I haven't seen this PR.

@sadhansood
Copy link
Contributor

Ah interesting. Could we follow up and maybe rename current clear to unsafe_clear and then add a safe version of clear? (and document well) Because I would totally make the same mistake if I haven't seen this PR.

Yeah sure, we can do that. I'll send out a follow up PR.

ebmifa pushed a commit that referenced this pull request Jul 12, 2023
because clear() drops and re-creates the table without holding a lock,
it can cause crashes if other threads happen to try to write to or read
from the table being cleared. I don't think it makes sense to add
locking to every DBMap access just to fix this case, so I'm just going
to avoid calling clear().
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants