This is an automated email from the ASF dual-hosted git repository. vatamane pushed a commit to branch fix-epoch-assert in repository https://gitbox.apache.org/repos/asf/couchdb.git
commit efcba14c0fe4d6f857757dad54986f8377d52f74 Author: Nick Vatamaniuc <[email protected]> AuthorDate: Fri Aug 2 13:49:57 2024 -0400 Fix epoch update sequence regression Previously, we asserted that the update sequence in the epoch doesn't regress during same node updates, and during node changes. However, we didn't consider case when the shards are compacting. When that happens the epochs are copied as is from the old header, so they may have higher update sequences, but the update sequence is set to the default (0) from the new header record instance. As a result, the assertion would fire during compaction in the initialization phase. --- src/couch/src/couch_bt_engine_header.erl | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/src/couch/src/couch_bt_engine_header.erl b/src/couch/src/couch_bt_engine_header.erl index 69be61949..b122a0319 100644 --- a/src/couch/src/couch_bt_engine_header.erl +++ b/src/couch/src/couch_bt_engine_header.erl @@ -274,8 +274,13 @@ upgrade_epochs(#db_header{} = Header) -> % just codifies that assumption. [{Node, 0}]; [{Node, S} | _] = Epochs0 -> - assert_monotonic_update_seq(Header, S), % Current node is the current owner of this db + % + % During regular updates we could assert that update sequence + % doesn't regress here. However, when compacting the new header + % starts at update_seq = 0 and continues incrementing as the + % compaction proceeds. In that case the epochs sequence could + % be regressing. Epochs0; [{_OtherNode, S} | _] = Epochs1 -> assert_monotonic_update_seq(Header, S),
