@@ -6,6 +6,42 @@ slug: 2024-06-14-newsletter
66type : newsletter
77layout : newsletter
88lang : en
9+
10+ qa :
11+ - question : What is the behavior change introduced by this PR?
12+ answer : |
13+ Behaviour is changed in three ways. First, as per the goal of this
14+ PR, optional indexes are no longer wiped again when the node is
15+ restarted before reindexing is completed. This aligns the wiping
16+ behavior of optional indexes with that of required indexes. Second,
17+ when a user requests a reindex through the GUI, this request is no
18+ longer ignored, reversing a subtle bug introduced in [b47bd95][gh
19+ b47bd95]. Third, the log line "Initializing databases...\\n" is
20+ removed.
21+ link : https://bitcoincore.reviews/30132#l-19
22+
23+ - question : What are the two ways an optional index can process new blocks?
24+ answer : |
25+ When an optional index is initialized, it checks if its highest
26+ block is the same as the current chaintip. If it is not, it will first
27+ process all missing blocks with a background sync, through
28+ `BaseIndex::StartBackgroundSync()`. When the index catches up
29+ with the chaintip, it will process all further blocks through the
30+ validation interface using `ValidationSignals::BlockConnected`.
31+ link : https://bitcoincore.reviews/30132#l-52
32+
33+ - question : How does this PR affect the logic of optional indexes processing new blocks?
34+ answer : |
35+ Before this PR, wiping the optional indexes without wiping the
36+ chainstate means these indexes will be considered out-of-sync. As per
37+ the previous question, that means they will first perform a background
38+ sync before switching to the validation interface. With this PR, the
39+ optional indexes remain in sync with the chainstate, and as such no
40+ background sync is required. Note: background sync only starts after
41+ reindex has completed, whereas processing validation events happens in
42+ parallel.
43+ link : https://bitcoincore.reviews/30132#l-70
44+
945---
1046This week's newsletter announces a draft BIP for a quantum-safe Bitcoin
1147address format and includes our regular sections with the summary of a
@@ -60,39 +96,7 @@ necessary.
6096
6197{% assign timestamp="23:28" %}
6298
63- {% include functions/details-list.md
64- q0="What is the behavior change introduced by this PR?"
65- a0="Behaviour is changed in three ways. First, as per the goal of this
66- PR, optional indexes are no longer wiped again when the node is
67- restarted before reindexing is completed. This aligns the wiping
68- behavior of optional indexes with that of required indexes. Second,
69- when a user requests a reindex through the GUI, this request is no
70- longer ignored, reversing a subtle bug introduced in [ b47bd95] [ gh
71- b47bd95] . Third, the log line \" Initializing databases...\\ n\" is
72- removed."
73- a0link="https://bitcoincore.reviews/30132#l-19 "
74-
75- q1="What are the two ways an optional index can process new blocks?"
76- a1="When an optional index is initialized, it checks if its highest
77- block is the same as the current chaintip. If it is not, it will first
78- process all missing blocks with a background sync, through
79- ` BaseIndex::StartBackgroundSync() ` . When the index catches up
80- with the chaintip, it will process all further blocks through the
81- validation interface using ` ValidationSignals::BlockConnected ` ."
82- a1link="https://bitcoincore.reviews/30132#l-52 "
83-
84- q2="How does this PR affect the logic of optional indexes processing
85- new blocks?"
86- a2="Before this PR, wiping the optional indexes without wiping the
87- chainstate means these indexes will be considered out-of-sync. As per
88- the previous question, that means they will first perform a background
89- sync before switching to the validation interface. With this PR, the
90- optional indexes remain in sync with the chainstate, and as such no
91- background sync is required. Note: background sync only starts after
92- reindex has completed, whereas processing validation events happens in
93- parallel."
94- a2link="https://bitcoincore.reviews/30132#l-70 "
95- %}
99+ {% include functions/pr-club.md %}
96100
97101## Releases and release candidates
98102
0 commit comments