<p>Flushing the dbcache is the mechanism by which the database on disk is brought in sync with the database in memory. Since the UTXO set constantly changes, it's more performant to cache the most recent changes in memory rather than writing everything out to disk immediately as disk I/O can be pretty slow.</p>
<p>Because entries contained in the dbcache are not always on disk, an event that kills bitcoind before the flush can occur (such as sudden power loss) results in those UTXO set changes being lost. But this is not catastrophic as long as we still have the blocks. We can just load up the chainstate with the most recent data, and go through those blocks again to update the chainstate.</p>
<p>With pruning, we are going to be deleting blocks. This introduces a situation where we have UTXO set changes in the dbcache but not on disk and the blocks originating those changes have been removed. If bitcoind were to be killed at this time, we would have no way of recovering the changes without re-downloading the blocks. By flushing the dbcache before removing the blk*.dat and undo*.dat files, we can ensure that the UTXO set on disk is up to date before the files are pruned.</p>

CC BY-SA 4.0
2023-01-16T16:36:57.773Z
Strictly speaking, I think it's only necessary to flush when pruning when the prune-point would become more recent than the last db flush, but I don't believe Bitcoin Core makes that distinction.
Pieter Wuille
CC BY-SA 4.0
2023-01-17T04:43:12.847Z
So is the reason for the dbcache flush just in case bitcoind is suddenly killed? If the assumption was that bitcoind will never get killed unexpectedly, would there be no reason to flush the dbcache?
kcalvinalvin
CC BY-SA 4.0
2023-01-17T15:15:32.367Z
Do I understand correctly that making that distinction might significantly speed up synchronization for pruning nodes, because they could make more use of the dbcache, @PieterWuille?
Murch
CC BY-SA 4.0
2023-01-17T15:34:11.320Z
@Murch Unless your prune size is pretty large, or the dbcache is really small, I don't think it'd make a difference.
Pieter Wuille
CC BY-SA 4.0
2023-01-16T16:31:09.260Z
2023-01-16T16:31:09.260Z
Ava Chow
<p>As I understand, when Bitcoin Core has pruning turned on, it will flush the dbcache when it prunes unnecessary blk*.dat and rev*.dat files during ibd.</p>
<p>In <a href="https://bitcoincore.reviews/20827" rel="nofollow noreferrer">https://bitcoincore.reviews/20827</a>, it states:</p>
<p>&quot;Pruning is a reason for us to flush the dbcache regardless of its memory usage. The maximum configured dbcache size is often not reached.&quot;</p>
<p>I don't understand the reasoning behind this flush. Even if you delete the *.dat files, the UTXO set should still be consistent and the ibd would function normally. I'm thinking there has to be some reason but I can't figure out why.</p>

<bitcoin-core><bitcoind><synchronization><pruning><utxo-set>
Why is there a need to flush the UTXO set when you prune blk*.dat and rev*.dat files during ibd?
kcalvinalvin
# Why is there a need to flush the UTXO set when you prune blk*.dat and rev*.dat files during ibd?

(Asked by: username_0 on 2023-01-16)

As I understand, when Bitcoin Core has pruning turned on, it will flush the dbcache when it prunes unnecessary blk\*.dat and rev\*.dat files during ibd.

In <https://bitcoincore.reviews/20827>, it states:

"Pruning is a reason for us to flush the dbcache regardless of its memory usage. The maximum configured dbcache size is often not reached."

I don't understand the reasoning behind this flush. Even if you delete the \*.dat files, the UTXO set should still be consistent and the ibd would function normally. I'm thinking there has to be some reason but I can't figure out why.

**Tags:** bitcoin-core, bitcoind, synchronization, pruning, utxo-set


---

## 1 answers

### Answer by username_1 on 2023-01-16. Score: 3 | Accepted answer

Flushing the dbcache is the mechanism by which the database on disk is brought in sync with the database in memory. Since the UTXO set constantly changes, it's more performant to cache the most recent changes in memory rather than writing everything out to disk immediately as disk I/O can be pretty slow.

Because entries contained in the dbcache are not always on disk, an event that kills bitcoind before the flush can occur (such as sudden power loss) results in those UTXO set changes being lost. But this is not catastrophic as long as we still have the blocks. We can just load up the chainstate with the most recent data, and go through those blocks again to update the chainstate.

With pruning, we are going to be deleting blocks. This introduces a situation where we have UTXO set changes in the dbcache but not on disk and the blocks originating those changes have been removed. If bitcoind were to be killed at this time, we would have no way of recovering the changes without re-downloading the blocks. By flushing the dbcache before removing the blk\*.dat and undo\*.dat files, we can ensure that the UTXO set on disk is up to date before the files are pruned.

> **Comments:**
> **username_2**: Strictly speaking, I think it's only necessary to flush when pruning when the prune-point would become more recent than the last db flush, but I don't believe Bitcoin Core makes that distinction.  
> **username_0**: So is the reason for the dbcache flush just in case bitcoind is suddenly killed? If the assumption was that bitcoind will never get killed unexpectedly, would there be no reason to flush the dbcache?  
> **username_3**: Do I understand correctly that making that distinction might significantly speed up synchronization for pruning nodes, because they could make more use of the dbcache, @username_2?  
> **username_2**: @username_3 Unless your prune size is pretty large, or the dbcache is really small, I don't think it'd make a difference.  

---

