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

Events database GC #12274

Closed
rvagg opened this issue Jul 23, 2024 · 3 comments
Closed

Events database GC #12274

rvagg opened this issue Jul 23, 2024 · 3 comments

Comments

@rvagg
Copy link
Member

rvagg commented Jul 23, 2024

Tie event lifetime to blockstore lifetime. Make this configurable but if you have a splitstore enabled then events shouldn't persist if you don't have the blocks available for them.

Needs some consideration though: eth_getLogs and GetActorEventsRaw I think should still work on old epochs even if you don't have the blocks, maybe that's desirable? We could make this configurable to either have a config option with "number of epochs to store" or "follow splitstore".

@BigLep
Copy link
Member

BigLep commented Aug 6, 2024

@rvagg : newbie question here: does this only apply for the events db, or do we need to cover the messages and transactions dbs as well?

@rvagg
Copy link
Member Author

rvagg commented Aug 7, 2024

txhash.db has a GC already

I think msgindex.db does a basic GC on lotus startup

It's events that's the main problem, because it doesn't have any, and it accumulates a lot quicker and gets a lot larger. But we could apply the same pattern to the others when we implement it.

@rjan90 rjan90 added this to the DX-Streamline milestone Aug 13, 2024
@BigLep
Copy link
Member

BigLep commented Oct 3, 2024

This is subsumed by work happening in #12453

@BigLep BigLep closed this as completed Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: ☑️ Done (Archive)
Development

No branches or pull requests

3 participants