diff options
author | Nick Vatamaniuc <vatamane@apache.org> | 2022-02-04 00:11:51 -0500 |
---|---|---|
committer | Nick Vatamaniuc <nickva@users.noreply.github.com> | 2022-02-11 17:55:51 -0500 |
commit | 24d6582dfd341b7c22fcabd8fb85217c923f7bb2 (patch) | |
tree | 311f1645f08e32d081ad8656df4f47964b0d435b /rel | |
parent | 81fe821496259718c91bb9554dbbb7d6a8988712 (diff) | |
download | couchdb-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.ini | 10 |
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 |