summaryrefslogtreecommitdiff
path: root/rel
diff options
context:
space:
mode:
authorNick Vatamaniuc <vatamane@apache.org>2022-02-04 00:11:51 -0500
committerNick Vatamaniuc <nickva@users.noreply.github.com>2022-02-11 17:55:51 -0500
commit24d6582dfd341b7c22fcabd8fb85217c923f7bb2 (patch)
tree311f1645f08e32d081ad8656df4f47964b0d435b /rel
parent81fe821496259718c91bb9554dbbb7d6a8988712 (diff)
downloadcouchdb-24d6582dfd341b7c22fcabd8fb85217c923f7bb2.tar.gz
Track libicu collator versions in the view header
Previously, libicu collator versions were not tracked, and during major OS version upgrades, it was possible to experience apparent data loss due to collation order changes between libicu library versions. The view order inconsistency would last until the view is compacted. This commit introduces a view info map in the header which records the list of libicu collator versions used by that view. The collator versions list is checked and updated every time a view is opened. The new view info map is re-using a previously removed view header field from 2.x views. The upgrade logic from 2.x to 3.x ignores that header field, and this allows for transparent downgrading back to 3.2.1, and then upgrading back to 3.2.1+ versions, all while keeping the same view signature. If there is no collator version recorded in the view header, the first time the view is opened, the header will be upgraded to record the current libicu version. It's possible to avoid immediately writting the upgraded header and instead delaying till the next view data update with this setting: ``` [view_upgrade] commit_on_header_upgrade = false ``` By default it's toggled to `true`, meaning the view header will be written immediately. The list of collator version is returned in the _design/*/_info response. This allows users to easily track the condition when the view is built or opened with more than one libicu collator versions. Views which have more than one collator versions are submitted for re-compaction to the "upgrade_views" channel. This behavior is triggered both on update (which is the typical smoosh trigger mechanism), and when opened. Triggering on open is inteded to be used with read-only views, which may not be updated after libicu upgrades, and so would perpetually emit inconsistent data. Automatic re-compaction may be disabled with a config setting: ``` [view_upgrade] compact_on_collator_upgrade = false ``` The default value is `true`.
Diffstat (limited to 'rel')
-rw-r--r--rel/overlay/etc/default.ini10
1 files changed, 10 insertions, 0 deletions
diff --git a/rel/overlay/etc/default.ini b/rel/overlay/etc/default.ini
index 93aa1ca59..3c15ae92c 100644
--- a/rel/overlay/etc/default.ini
+++ b/rel/overlay/etc/default.ini
@@ -718,3 +718,13 @@ partitioned||* = true
additional_port = false
bind_address = 127.0.0.1
port = {{prometheus_port}}
+
+[view_upgrade]
+; When enabled, views with more than one collator versions will be submitted
+; for auto-compaction to smoosh's "upgrade_views" channel.
+;compact_on_collator_upgrade = true
+
+; Eagerly commit views which been upgraded from older header formats. A reason
+; to disable this setting could be if the views need an upgrade but located on
+; read-only file system.
+;commit_on_header_upgrade = true