Import wiredtiger: 7b4995aa525fefb8ae1422261a05000c32d8104d from branch mongodb-master

ref: 0175c62aa9..7b4995aa52
for: 5.1.0

WT-8024       Add link text to cross-references in Arch Guide

13 files changed, 57 insertions, 54 deletions

diff --git a/src/third_party/wiredtiger/import.data b/src/third_party/wiredtiger/import.data
index 3563583f598..d2d27e65202 100644
--- a/src/third_party/wiredtiger/import.data
+++ b/src/third_party/wiredtiger/import.data
@@ -2,5 +2,5 @@
     "vendor": "wiredtiger",
     "github": "wiredtiger/wiredtiger.git",
     "branch": "mongodb-master",
-    "commit": "0175c62aa93bd5371c0ddafba2e49d6f9dfd67cd"
+    "commit": "7b4995aa525fefb8ae1422261a05000c32d8104d"
 }
diff --git a/src/third_party/wiredtiger/src/docs/arch-block.dox b/src/third_party/wiredtiger/src/docs/arch-block.dox
index 1738d2fdb9b..d5f7b6dff1e 100644
--- a/src/third_party/wiredtiger/src/docs/arch-block.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-block.dox
@@ -150,7 +150,7 @@ API is called. See \c bt_io.c for more detail.
 
 @subsubsection Checkpoint
 
-For details on checkpoint at the WiredTiger level see: @ref arch-checkpoint.
+For details on checkpoint at the WiredTiger level see: @ref arch-checkpoint "Checkpoint".
 
 At the block manager level, a checkpoint corresponds with a set of blocks that
 are stored in the file associated with the given URI. Typically each file will
@@ -223,7 +223,7 @@ range in the file, that is, any number of contiguous blocks.
 
 @subsubsection Eviction
 
-For more detail on how WiredTiger eviction works see: @ref arch-eviction.
+For more detail on how WiredTiger eviction works see: @ref arch-eviction "Eviction".
 
 Eviction also utilizes the block manager. When a page is evicted and contains
 data that needs to be maintained, logically a block needs to be written.
diff --git a/src/third_party/wiredtiger/src/docs/arch-connection.dox b/src/third_party/wiredtiger/src/docs/arch-connection.dox
index cdc3eeecb9a..4b63bd02dfe 100644
--- a/src/third_party/wiredtiger/src/docs/arch-connection.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-connection.dox
@@ -13,7 +13,8 @@ connection is represented by \c WT_CONNECTION.
 A connection is initialized when WT_CONNECTION::wiredtiger_open is called by the user application.
 WT_CONNECTION::wiredtiger_open accepts a list of configuration items (see @ref database_config) that
 can be used to enable different WiredTiger features and tune their behavior. Those features are for
-example related to @ref arch-eviction, @ref arch-logging, @ref arch-checkpoint, @ref arch-cache,
+example related to @ref arch-eviction "Eviction", @ref arch-logging "Logging",
+@ref arch-checkpoint "Checkpoints", @ref arch-cache "Caching",
 statistics, etc. All the different available configuration settings are described in the
 documentation for WT_CONNECTION::wiredtiger_open.
 
@@ -32,17 +33,17 @@ database.
 Once the database has been successfully opened, internal worker threads are started to provide
 global services used at runtime. Those services consist of different threads to handle statistics,
 logging, eviction, checkpoint and cache management. The sweeping server that manages the active and
-inactive dhandles is started too, see @ref arch-dhandle for more information.
+inactive dhandles is started too, see @ref arch-dhandle "Data Handles" for more information.
 
 Finally, before the connection is completely initialized, the database is set to a consistent state
-by running rollback to stable, see @ref arch-rts for more details.
+by running @ref arch-rts "rollback to stable".
 
 @subsection arch_conn_runtime Runtime
 
 At runtime, database-wide operations can be executed using the connection interface. For instance,
 it is possible to reconfigure WiredTiger features and behavior using WT_CONNECTION::reconfigure
 instead of closing the connection and calling WT_CONNECTION::open again. However, almost all CRUD
-operations on the database are executed in the context of a session (see @ref arch-session) which
+operations on the database are executed in the context of a @ref arch-session "Session" which
 can be created using WT_CONNECTION::open_session. See the WT_CONNECTION:: documentation to discover
 other available APIs related to WiredTiger connections.
 
diff --git a/src/third_party/wiredtiger/src/docs/arch-cursor.dox b/src/third_party/wiredtiger/src/docs/arch-cursor.dox
index 7eee860af86..4b29d8f39b4 100644
--- a/src/third_party/wiredtiger/src/docs/arch-cursor.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-cursor.dox
@@ -146,7 +146,7 @@ With projections, the simple algorithm following the plan works well if the colu
 are grouped by column group and requested in order.  Without that discipline, as in this example,
 the performance will not be optimal.
 
-The implementation of plan creation and execution resides in the @ref arch-schema.
+The implementation of plan creation and execution resides in the @ref arch-schema "Schema".
 
 @section arch_cursor_dump Dump cursors
 
diff --git a/src/third_party/wiredtiger/src/docs/arch-hs.dox b/src/third_party/wiredtiger/src/docs/arch-hs.dox
index c6453108f03..862ce7442d0 100644
--- a/src/third_party/wiredtiger/src/docs/arch-hs.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-hs.dox
@@ -42,7 +42,8 @@ possible timestamp (\c WT_TS_MAX). The stop timestamp of the latest update in th
 updated once the prepared update is resolved. A tombstone becomes globally visible if the stop
 timestamp is less than the oldest timestamp and the stop transaction id is visible to all concurrent
 transactions in the system. A checkpoint can delete history store pages that only contain globally
-visible tombstones. The garbage collection process is discussed in @ref arch-checkpoint.
+visible tombstones. The garbage collection process is discussed in @ref arch-checkpoint
+"Checkpoint".
 
 @section arch_hs_initialize History store initialization
 WiredTiger checks for an existing history store table at startup and creates a new table if it is
@@ -237,7 +238,7 @@ created without records which have globally visible tombstones. This ensures tha
 only keeping the relevant historical data required to serve the oldest reader in the system or
 as dictated by the oldest timestamp set by the application. Once all records on a page are obsolete,
 the page itself can be removed to reduce the size of the history store table
-(see @ref arch-transaction for more details about oldest timestamp).
+(see @ref arch-transaction "Transaction" for more details about oldest timestamp).
 
 @section arch_hs_read Searching for older versions of a key in History Store
 When looking for an update visible to the current transaction, WiredTiger first searches the update
@@ -251,13 +252,13 @@ in the history store for a key and read timestamp combination, each update would
 visibility based on transaction and timestamp based visibility rules. In case there are no records
 visible in the history store table, \c WT_NOTFOUND error is returned to the reader.
 
-@section arch_hs_rts History store and rollback-to-stable
-Rollback-to-stable searches the history store table for valid updates that are stable according to
+@section arch_hs_rts History store and rollback to stable
+@ref arch-rts "Rollback to stable" searches the history store table for valid updates that are
+stable according to
 the supplied stable timestamp and replaces the on-disk version with an update from the history store
-table that fulfills the criteria. Rollback-to-stable also removes updates from the
+table that fulfills the criteria. Rollback to stable also removes updates from the
 history store table that are not stable according to the stable timestamp and transaction snapshot
-being used for rollback-to-stable operation. More details about the rollback-to-stable operation
-can be found in the @ref arch-rts page.
+being used for rollback to stable operation.
 
 @section arch_hs_prepared History store and prepared transactions
 When there is a prepared update for a key and the page is evicted, the prepared update is written
diff --git a/src/third_party/wiredtiger/src/docs/arch-index.dox b/src/third_party/wiredtiger/src/docs/arch-index.dox
index 906e6959be8..2ea5717c9d1 100644
--- a/src/third_party/wiredtiger/src/docs/arch-index.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-index.dox
@@ -122,94 +122,94 @@ wt_file -[hidden]right-> log_file
 
 We go into some detail for some of the internal components.
 
-@subpage arch-backup
+@subpage arch-backup "Backup"
 
 Hot backup uses a type of cursor to backup the database.
 
-@subpage arch-block
+@subpage arch-block "Block Manager"
 
 The Block Manager manages the reading and writing of disk blocks.
 
-@subpage arch-cache
+@subpage arch-cache "Cache"
 
 Cache is represented by the various shared data structures that
 make up in-memory Btrees and subordinate data structures.
 
-@subpage arch-checkpoint
+@subpage arch-checkpoint "Checkpoint"
 
 A checkpoint is created by WiredTiger to serve as a point from which it can recover.
 
-@subpage arch-connection
+@subpage arch-connection "Connection"
 
 A connection is a handle to a WiredTiger database instance.
 
-@subpage arch-cursor
+@subpage arch-cursor "Cursor"
 
 Cursors are used to get and modify data.
 
-@subpage arch-data-file
+@subpage arch-data-file "Data File Format"
 
 The format of the data file is given by structures in \c block.h .
 
-@subpage arch-dhandle
+@subpage arch-dhandle "Data Handles"
 
 An internal structure called a Data Handle (dhandle) is used to represent and
 access Btrees and other data sources in WiredTiger.
 
-@subpage arch-eviction
+@subpage arch-eviction "Eviction"
 
 Eviction represents the process or removing old data from the cache,
 writing it to disk if it is dirty.
 
-@subpage arch-fs-os
+@subpage arch-fs-os "File System and Operating System Interface"
 
 A layer of abstraction is above all operating system calls and
 a set of functions can be registered to be called for each file system
 operation.
 
-@subpage arch-hs
+@subpage arch-hs "History Store"
 
 The History Store tracks old versions of records.
 
-@subpage arch-logging
+@subpage arch-logging "Logging"
 
 WiredTiger writes all changes into a write-ahead log when configured.
 
-@subpage arch-log-file
+@subpage arch-log-file "Log File Format"
 
 The format of a log file is defined in \c log.h .
 
-@subpage arch-metadata
+@subpage arch-metadata "Metadata"
 
 Metadata is stored as <code>uri, config</code> K/V pairs in a designated table.
 
-@subpage arch-python
+@subpage arch-python "Python API"
 
 WiredTiger has a Python API that is useful for scripting and experimentation.
 
-@subpage arch-row-column
+@subpage arch-row-column "Row Store and Column Store"
 
 Row stores and column store are B-Trees. Row stores have a variable size key and data while column
 stores have as their key a record id.
 
-@subpage arch-rts
+@subpage arch-rts "Rollback to Stable"
 
 Rollback to stable to remove the unstable updates from the database.
 
-@subpage arch-schema
+@subpage arch-schema "Schema"
 
 A schema defines the format of the application data in WiredTiger.
 
-@subpage arch-session
+@subpage arch-session "Session"
 
 A session defines the context for most operations performed in WiredTiger.
 
-@subpage arch-snapshot
+@subpage arch-snapshot "Snapshot"
 
 Snapshots are implemented by storing transaction ids committed before
 the transaction started.
 
-@subpage arch-transaction
+@subpage arch-transaction "Transactions"
 
 Transactions provide a powerful abstraction for multiple threads to operate on data concurrently.
 
diff --git a/src/third_party/wiredtiger/src/docs/arch-log-file.dox b/src/third_party/wiredtiger/src/docs/arch-log-file.dox
index 1ff828052db..a4d544d595f 100644
--- a/src/third_party/wiredtiger/src/docs/arch-log-file.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-log-file.dox
@@ -1,7 +1,7 @@
 /*! @arch_page arch-log-file Log File Format
 
 This page assumes familiarity with the logging subsystem. Please see
-@ref arch-logging for the logging subsystem architecture description.
+@ref arch-logging "Logging" for a description of that subsystem.
 
 Each log file begins with a fixed length header, followed by a set of
 variable length log records. The fixed length header contains information
diff --git a/src/third_party/wiredtiger/src/docs/arch-logging.dox b/src/third_party/wiredtiger/src/docs/arch-logging.dox
index aea99aa094f..fe36a9c6589 100644
--- a/src/third_party/wiredtiger/src/docs/arch-logging.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-logging.dox
@@ -167,8 +167,7 @@ in the case of crash or failure. When the system is restarted, WiredTiger will a
 run recovery. If the system previously shutdown cleanly, then recovery determines that
 the log does not need to be replayed. Otherwise, recovery replays all operations from
 the LSN of the most recent checkpoint. When timestamps are in use, recovery also
-performs a rollback-to-stable operation on tables that are not logged.
-This aspect of recovery is discussed in @ref arch-rts.
+performs a @ref arch-rts "rollback to stable" operation on tables that are not logged.
 
 Users can access and view the records in the log using one of two methods. The most
 common method is via the \c wt printlog command. The command utility will print the
diff --git a/src/third_party/wiredtiger/src/docs/arch-row-column.dox b/src/third_party/wiredtiger/src/docs/arch-row-column.dox
index d7d10f54795..affd8ea3e16 100644
--- a/src/third_party/wiredtiger/src/docs/arch-row-column.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-row-column.dox
@@ -1,4 +1,4 @@
-/*! @arch_page arch-row-column Row Store & Column Store
+/*! @arch_page arch-row-column Row Store and Column Store
 
 @section row_column_definition Definition
 
@@ -14,8 +14,8 @@ column store is created. The fixed length column store has specialized use cases
 - The variable length is a more general case which allows for values to have any length similarly to
 row-stores.
 
-Please refer to @ref arch-data-file to learn more about the on-disk format for row-stores and
-column-stores.
+Please refer to @ref arch-data-file "Data File Format" to learn more about the on-disk format for
+row-stores and column-stores.
 
 @section row_column_rs Row-stores
 
diff --git a/src/third_party/wiredtiger/src/docs/arch-rts.dox b/src/third_party/wiredtiger/src/docs/arch-rts.dox
index 3e2cf6b70d0..7e469a5979a 100644
--- a/src/third_party/wiredtiger/src/docs/arch-rts.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-rts.dox
@@ -1,4 +1,4 @@
-/*! @arch_page arch-rts Rollback to stable
+/*! @arch_page arch-rts Rollback to Stable
 
 Rollback to stable is an operation that retains only the modifications that
 are stable according to the stable timestamp and recovered checkpoint snapshot.
@@ -8,7 +8,7 @@ checkpoint are recovered and used as a recovered checkpoint snapshot.
 @section rts-overview Overview of rollback to stable
 
 Rollback to stable scans each and every table present in the database except
-metadata @ref arch-metadata to remove the modifications from the table
+@ref arch-metadata "Metadata" to remove the modifications from the table
 that are more than stable timestamp and recovered checkpoint snapshot.
 
 In the process of removing newer modifications from the table, all the in-memory
diff --git a/src/third_party/wiredtiger/src/docs/arch-schema-ops.dox b/src/third_party/wiredtiger/src/docs/arch-schema-ops.dox
index 5d647a05205..69efbd6bbb4 100644
--- a/src/third_party/wiredtiger/src/docs/arch-schema-ops.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-schema-ops.dox
@@ -1,6 +1,6 @@
 /*! @page arch-schema-ops Schema Operations
 
-A @ref arch-schema defines the format of the application data in WiredTiger.
+A @ref arch-schema "Schema" defines the format of the application data in WiredTiger.
 This section details the internals of various schema operations.
 
 Schema operations cause an update to the metadata and are performed under a
diff --git a/src/third_party/wiredtiger/src/docs/arch-session.dox b/src/third_party/wiredtiger/src/docs/arch-session.dox
index e17eca10b1b..bd72302d2d7 100644
--- a/src/third_party/wiredtiger/src/docs/arch-session.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-session.dox
@@ -1,7 +1,8 @@
 /*! @arch_page arch-session Session
 
 @section arch_session_def Definition
-After a @ref arch-connection has been established between the application and WiredTiger, the
+After a @ref arch-connection "Connection" has been established between the application and
+WiredTiger, the
 application can start sending requests to WiredTiger using a session. A session is internally
 represented by WT_SESSION and plays an important role since almost all operations are performed
 under the context of a session.
@@ -13,7 +14,7 @@ associated with one connection. The maximum number of sessions is set through th
 \c session_max as part of the configuration string in ::wiredtiger_open.
 
 Sessions created by the calling application are called "user sessions". WiredTiger also performs
-some internal operations such as @ref arch-eviction through self-created sessions. These sessions
+some internal operations such as @ref arch-eviction "Eviction" through self-created sessions. These sessions
 are called "internal sessions". The usage rules and guidelines for both internal sessions and user
 sessions are the same and the only difference between them is their origin of creation.
 
@@ -24,23 +25,24 @@ documentation related to WT_SESSION.
 
 @section arch_session_txn Transactions
 It is possible to group several operations within a session, in other words, multiple operations can
-be treated as a single atomic operation. This can be done using @ref arch-transaction. Furthermore,
+be treated as a single atomic operation. This can be done using @ref arch-transaction
+"Transactions". Furthermore,
 a session can hold only one running transaction at any given time and this transaction only belongs
 to that session.
 
 @section arch_session_cur Cursors
 A session can perform multiple data operations on one or several collections using multiple cursors
-(see @ref arch-cursor for more details). All the cursors associated with a session share that
+(see @ref arch-cursor "Cursor" for more details). All the cursors associated with a session share that
 session transaction context. It is also possible to cache those cursors if required through the
 configuration string given to WT_CONNECTION::open_session or ::wiredtiger_open. The configuration
 item for this purpose is \c cache_cursors.
 
 @section arch_session_dhandles Data Handles
-During its lifetime, a session can accumulate a list of data handles (see @ref arch-dhandle).
+During its lifetime, a session can accumulate a list of data handles (see @ref arch-dhandle "Data Handles").
 Indeed, when a session accesses a table for the first time, the data handle of that table is
 acquired and cached. Once a session no longer needs to operate on a table, it marks the associated
 data handle as idle. This helps the sweep server release data handles that are inactive, see @ref
-arch-dhandle-lifecycle for more details.
+arch-dhandle-lifecycle "Data Handle Lifecycle" for more details.
 
 @section arch_session_closure Closure
 A session can be closed using WT_SESSION::close. Closing the connection will also close all opened
diff --git a/src/third_party/wiredtiger/src/docs/arch-transaction.dox b/src/third_party/wiredtiger/src/docs/arch-transaction.dox
index c1be0f99394..c9272356717 100644
--- a/src/third_party/wiredtiger/src/docs/arch-transaction.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-transaction.dox
@@ -159,7 +159,7 @@ store to check if there is a version visible to the reader there.
 @subsection Durability
 
 WiredTiger transactions support commit level durability and checkpoint level durability. An
-operation is commit level durable if logging is enabled on the table (@ref arch-logging). After it
+operation is commit level durable if @ref arch-logging "Logging" is enabled on the table. After it
 has been successfully committed, the operation is guaranteed to survive restart. An operation will
 only survive across restart under checkpoint durability if it is included in the last successful
 checkpoint.
@@ -182,8 +182,8 @@ timestamp, which may cause excessive amounts of data to be pinned in memory. The
 is allowed to move beyond the prepared timestamp and at the commit time, the prepared transaction
 can then be committed after the current stable timestamp with a larger durable timestamp. The
 durable timestamp also marks the time the update is to be stable. If the stable timestamp is moved
-to or beyond the durable timestamp of an update, it will not be removed by rollback to stable from
-a checkpoint. See @ref arch-rts for more details.
+to or beyond the durable timestamp of an update, it will not be removed from a checkpoint by
+@ref arch-rts "rollback to stable".
 
 The visibility of the prepared transaction is also special when in the prepared state. Since in the
 prepared state, the transaction has released its snapshot, it should be visible to the transactions