ReadOnly: i think we don’t need it. Non-ReadOnly allow mdbx to auto-recover from “safe_no_sync power-off” state. i think we must not use ReadOnly anywhere in Erigon tooling.

Accede: we need because we don’t know all that cli flags to create db (geometry and pageSize).

WithConfig - nice trick.

But if we don’t use ReadOnly - then maybe we can run_migrations on db to create tables. But it’s big question - which tool is lower level “migrations” or “seg reset” (what depends on what).

Also 1 long-standing issue: Capli using separated DB but same schema with ChainDB - i thin we need split Caplin schema in future.
(And drop some Erigon2 legacy tables - which using in couple unit-tests only. And don’t crate new tables for every new feature :-) )

Also “read chaindata vs pass —chain flag” is very old chiken-egg problem - i think we must have good tooling for this problem.

Drop legacy Table from schema - also old problem which we didn’t invest time into. It-theory it must be doable - in practice likely various erigon versions will return error - if some table will not exist (or maybe it will be not real problem if we will remove ReadOnly mode usage).

Also Acceede allows us to start RPCD with Erigon in-parallel and don’t scare of race-risk (but it’a alao ephomeral risk - mecause mdbx support cross-process guarantee of 1-rwtx-at-a-time a means no race, no conflicts)

Thanks so much for the detailed review @AskAlexSharov.

So ReadOnly - yes you are correct, I have dropped .Readonly(true) now. MDBX can do its auto-recovery correctly without it, if the DB wasn't shutdown cleanly (like after power cut or crash). And this is also in line with how dbCfg in snapshots_cmd.go opens the DB - just Accede(true) without Readonly.

For Accede - agreed, we need it because we simply don't have the geometry, page size and map size configuration available here to build the DB from scratch. One interesting thing I noticed going through CreateTable in kv_mdbx.go - both ReadOnly and Accede independently suppress the mdbx.Create flag. Even after removing the ReadOnly, Accede alone will still prevent the automatic creation of missing tables. For auto-creation we'd need normal RW mode (like node.OpenDatabase) but that seems risky for a maintenance tool like snapshots reset.

Regarding the named config - done, I extracted it to ChaindataSchemaForGenesis as you suggested and updated the tests to use the same as well.

For the migrations question I think snapshots reset should stay a lower level recovery tool. That's the whole reason why someone runs it is because their snapshots are broken or mismatched. If we try to run migrations inside it we might end up in a bad state mutating the DB. WithTableCfg(ChaindataSchemaForGenesis) keeps it clean, we just read the genesis hash and chain config, nothing more.

And yes, To open the DB we need the schema but to run migrations we need the chain name first. ChaindataSchemaForGenesis (which is used by the genesis hash and config) gives us a minimal profile with meta-data only that is valid across all chain versions.

For legacy tables - actually the infrastructure is already in place. In tables.go, ChaindataDeprecatedTables marks old E2 tables as deprecated and openDBIs ignores them. But completely removing them from old databases would require careful ordering of migration across versions, so that is a separate effort.

For RPCD and Accede - yes, mostly it is about avoiding geometry mismatches. Race conditions are not really an issue with MDBX since it has native handling of the cross-process 1-RW-tx guarantee.

My feeling is that we could generalise ChaindataSchemaForGenesis so that other tools, like the downloader's checkChainName or snapshot subcommands, could also use it for chain detection without crashing on unmigrated databases.

will need cherry-pick this PR to release/3.5 branch