rpc: gettxoutsetinfo locks m_cs_chainstate #16993

1. 
   Sjors commented at 10:12 am on September 30, 2019: member

   It seems unsafe to connect / disconnect / activate blocks while collecting stats about the current chain state.

   Making a UTXO snapshot in #16899 relies on invaliding a early block to roll back to the chain, calling gettxoutsetinfo and then calling reconsiderblock to return to the tip. I managed to end up with a corrupt chainstate doing this. Perhaps this was a result of #16444, but I also noticed that gettxoutsetinfo only returned once it reached the tip.

   I’m not sure if this is the right approach though.

   This might also help with #16979

2. [validation] make m_cs_chainstate public 70ba01a301
3. [rpc] gettxoutsetinfo: lock m_cs_chainstate 4610b2c297
4. 
   laanwj commented at 10:24 am on September 30, 2019: member

   The rationale for not doing this has always been that LevelDB makes an implicit snapshot, allowing the statistics to be done on this snapshot while the main database is being updated. This makes it possible to run them without blocking the entire process for an operation that can take quite long.
5. laanwj added the label RPC/REST/ZMQ on Sep 30, 2019
6. 
   Sjors commented at 10:52 am on September 30, 2019: member

   Come to think of it, I think it was not gettxoutsetinfo that returned late, but actually the new dumptxoutset. If gettxoutsetinfo works on a level db snapshot then indeed this extra lock shouldn’t be needed.
7. Sjors closed this on Sep 30, 2019

   ---

8. DrahtBot locked this on Dec 16, 2021

Contributors
Sjors laanwj

Labels
RPC/REST/ZMQ