Import wiredtiger: 6bfcab58b39232366daf8448c0cba29b7f170042 from branch mongodb-master

ref: 41b2d937fc..6bfcab58b3
for: 5.3.0

WT-7563       Refresh WiredTiger documentation

20 files changed, 435 insertions, 578 deletions

diff --git a/src/third_party/wiredtiger/dist/api_data.py b/src/third_party/wiredtiger/dist/api_data.py
index f5792a646e2..cf522b0f1d4 100644
--- a/src/third_party/wiredtiger/dist/api_data.py
+++ b/src/third_party/wiredtiger/dist/api_data.py
@@ -651,9 +651,8 @@ connection_runtime_config = [
         Config('table_logging', 'false', r'''
             if true, write transaction related information to the log for all
             operations, even operations for tables with logging turned off.
-            This setting introduces a log format change that may break older
-            versions of WiredTiger. These operations are informational and
-            skipped in recovery.''',
+            This additional logging information is intended for debugging and
+            is informational only, that is, it is ignored during recovery''',
             type='boolean'),
         Config('update_restore_evict', 'false', r'''
             if true, control all dirty page evictions through forcing update restore eviction.''',
@@ -1651,7 +1650,7 @@ methods = {
         set commit_timestamp.  \c first_commit returns the first set
         commit_timestamp.  \c prepare returns the timestamp used in preparing a
         transaction.  \c read returns the timestamp at which the transaction is
-        reading at.  See @ref transaction_timestamps''',
+        reading at.  See @ref timestamp_txn_api''',
         choices=['commit', 'first_commit', 'prepare', 'read']),
 ]),
 
@@ -1759,21 +1758,21 @@ methods = {
     Config('read_before_oldest', 'false', r'''
         allows the caller to specify a read timestamp less than the oldest timestamp but newer
         than or equal to the pinned timestamp. Cannot be set to true while also rounding up the read
-        timestamp. See @ref transaction_timestamps''', type='boolean'),
+        timestamp.''', type='boolean', undoc=True),
     Config('read_timestamp', '', r'''
         read using the specified timestamp.  The supplied value must not be
         older than the current oldest timestamp.  See
-        @ref transaction_timestamps'''),
+        @ref timestamp_txn_api'''),
     Config('roundup_timestamps', '', r'''
         round up timestamps of the transaction. This setting alters the
         visibility expected in a transaction. See @ref
-        transaction_timestamps''',
+        timestamp_roundup''',
         type='category', subconfig= [
         Config('prepared', 'false', r'''
             applicable only for prepared transactions. Indicates if the prepare
             timestamp and the commit timestamp of this transaction can be
-            rounded up. If the prepare timestamp is less than the oldest
-            timestamp, the prepare timestamp  will be rounded to the oldest
+            rounded up. If the prepare timestamp is less than the stable
+            timestamp, the prepare timestamp will be rounded to the stable
             timestamp. If the commit timestamp is less than the prepare
             timestamp, the commit timestamp will be rounded up to the prepare
             timestamp''', type='boolean'),
@@ -1789,18 +1788,23 @@ methods = {
 ]),
 
 'WT_SESSION.commit_transaction' : Method([
+    # FIXME-WT-8630: needs to be updated with the resolution of WT-8630. (XXX)
+    # (Maybe will need to be updated to say that for a prepared transaction only one
+    # commit timestamp may be set; otherwise likely unchanged.)
     Config('commit_timestamp', '', r'''
-        set the commit timestamp for the current transaction.  The supplied
-        value must not be older than the first commit timestamp set for the
-        current transaction.  The value must also not be older than the
-        current oldest and stable timestamps.  See
-        @ref transaction_timestamps'''),
+        set the commit timestamp for the current transaction. The supplied value
+        must not be older than the first commit timestamp already set for the
+        current transaction, if any. The value must also not be older than the
+        current oldest and stable timestamps. A commit timestamp is required for
+        the commit of a prepared transaction. If the prepare timestamp has been
+        set (because the transaction has been prepared), the commit timestamp must
+        not be older than it. See @ref timestamp_txn_api'''),
     Config('durable_timestamp', '', r'''
-        set the durable timestamp for the current transaction.  The supplied
-        value must not be older than the commit timestamp set for the
-        current transaction.  The value must also not be older than the
-        current stable timestamp.  See
-        @ref transaction_timestamps'''),
+        set the durable timestamp for the current transaction. Required for the
+        commit of a prepared transaction, and otherwise not permitted. The
+        supplied value must not be older than the commit timestamp set for the
+        current transaction. The value must also not be older than the current
+        oldest and stable timestamps. See @ref timestamp_prepare'''),
     Config('operation_timeout_ms', '0', r'''
         when non-zero, a requested limit on the time taken to complete operations in this
         transaction. Time is measured in real time milliseconds from the start of each WiredTiger
@@ -1811,39 +1815,57 @@ methods = {
     Config('sync', '', r'''
         override whether to sync log records when the transaction commits,
         inherited from ::wiredtiger_open \c transaction_sync.  The \c off setting does not
-        wait for record to be written or synchronized.  The
+        wait for records to be written or synchronized.  The
         \c on setting forces log records to be written to the storage device''',
         choices=['off', 'on']),
 ]),
 
 'WT_SESSION.prepare_transaction' : Method([
+    # FIXME-WT-8630: needs to be updated with the resolution of WT-8630. (XXX)
+    # (Looks like: either at most one commit timestamp may be set, or the commit
+    # timestamp may not be set before prepare, which of these TBD.)
     Config('prepare_timestamp', '', r'''
         set the prepare timestamp for the updates of the current transaction.
-        The supplied value must not be older than any active read timestamps.
-        See @ref transaction_timestamps'''),
+        The supplied value must not be older than any active read timestamps, must
+        not be older than the current stable timestamp, and must not be newer than
+        any commit timestamps already set. See @ref timestamp_prepare'''),
 ]),
 
 'WT_SESSION.timestamp_transaction' : Method([
+    # FIXME-WT-8630: needs to be updated with the resolution of WT-8630. (XXX)
+    # (Looks like: for a prepared transaction, either at most one commit timestamp
+    # may be set, or the commit timestamp may not be set before prepare, which of
+    # these TBD.)
     Config('commit_timestamp', '', r'''
-        set the commit timestamp for the current transaction.  The supplied
-        value must not be older than the first commit timestamp set for the
-        current transaction.  The value must also not be older than the
-        current oldest and stable timestamps.  See
-        @ref transaction_timestamps'''),
+        set the commit timestamp for the current transaction. The supplied value
+        must not be older than the first commit timestamp already set for the
+        current transaction, if any. The value must also not be older than the
+        current oldest and stable timestamps. A commit timestamp is required for
+        the commit of a prepared transaction.  If the prepare timestamp has
+        already been set, the commit timestamp must not be older than it. See
+        @ref timestamp_txn_api'''),
     Config('durable_timestamp', '', r'''
-        set the durable timestamp for the current transaction.  The supplied
-        value must not be older than the commit timestamp set for the
-        current transaction.  The value must also not be older than the
-        current stable timestamp.  See
-        @ref transaction_timestamps'''),
+        set the durable timestamp for the current transaction. Required for the
+        commit of a prepared transaction, and otherwise not permitted. Can only
+        be set once the current transaction has been prepared, and a commit
+        timestamp has been set. The supplied value must not be older than the
+        commit timestamp. The value must also not be older than the current
+        oldest and stable timestamps. See @ref timestamp_prepare'''),
+    # FIXME-WT-8630: needs to be updated with the resolution of WT-8630. (XXX)
+    # (One possible resolution is to prohibit setting the prepare timestamp before
+    # actually committing the transaction.)
     Config('prepare_timestamp', '', r'''
         set the prepare timestamp for the updates of the current transaction.
-        The supplied value must not be older than any active read timestamps.
-        See @ref transaction_timestamps'''),
+        The supplied value must not be older than any active read timestamps,
+        and must not be older than the current stable timestamp.
+        May be set only once per transaction, and must be set before setting the
+        commit timestamp. Setting the prepare timestamp does not by itself
+        prepare the transaction, but does oblige the application to eventually
+        prepare the transaction before committing it. See @ref timestamp_prepare'''),
     Config('read_timestamp', '', r'''
         read using the specified timestamp.  The supplied value must not be
         older than the current oldest timestamp.  This can only be set once
-        for a transaction. See @ref transaction_timestamps'''),
+        for a transaction. See @ref timestamp_txn_api'''),
 ]),
 
 'WT_SESSION.rollback_transaction' : Method([
@@ -1958,7 +1980,7 @@ methods = {
         shutdown and \c stable_timestamp returns the most recent \c stable_timestamp set with
         WT_CONNECTION::set_timestamp. (The \c oldest and \c stable arguments are deprecated
         short-hand for \c oldest_timestamp and \c stable_timestamp, respectively.) See @ref
-        transaction_timestamps''',
+        timestamp_global_api''',
         choices=['all_durable','last_checkpoint','oldest',
             'oldest_reader','oldest_timestamp','pinned','recovery','stable','stable_timestamp']),
 ]),
@@ -1971,7 +1993,7 @@ methods = {
         timestamp moves the tracked durable timestamp forwards.  This is only
         intended for use where the application is rolling back locally committed
         transactions. The supplied value must not be older than the current
-        oldest and stable timestamps.  See @ref transaction_timestamps'''),
+        oldest and stable timestamps.  See @ref timestamp_global_api'''),
     Config('force', 'false', r'''
         set timestamps even if they violate normal ordering requirements.
         For example allow the \c oldest_timestamp to move backwards''',
@@ -1981,14 +2003,14 @@ methods = {
         timestamp.  Supplied values must be monotonically increasing, any
         attempt to set the value to older than the current is silently ignored.
         The supplied value must not be newer than the current
-        stable timestamp.  See @ref transaction_timestamps'''),
+        stable timestamp.  See @ref timestamp_global_api'''),
     Config('stable_timestamp', '', r'''
         checkpoints will not include commits that are newer than the specified
         timestamp in tables configured with \c log=(enabled=false).  Supplied
         values must be monotonically increasing, any attempt to set the value to
         older than the current is silently ignored.  The supplied value must
         not be older than the current oldest timestamp.  See
-        @ref transaction_timestamps'''),
+        @ref timestamp_global_api'''),
 ]),
 
 'WT_CONNECTION.rollback_to_stable' : Method([]),
diff --git a/src/third_party/wiredtiger/dist/docs_data.py b/src/third_party/wiredtiger/dist/docs_data.py
index addbf1b5ad1..b9a36fc21dc 100644
--- a/src/third_party/wiredtiger/dist/docs_data.py
+++ b/src/third_party/wiredtiger/dist/docs_data.py
@@ -98,6 +98,9 @@ arch_doc_pages = [
     ArchDocPage('arch-snapshot',
         ['WT_TXN'],
         ['src/include/txn.h']),
+    ArchDocPage('arch-timestamp',
+        ['WT_TIME_AGGREGATE', 'WT_TIME_WINDOW'],
+        ['src/include/timestamp.h', 'src/include/timestamp_inline.h']),
     ArchDocPage('arch-transaction',
         ['WT_TXN', 'WT_TXN_GLOBAL', 'WT_TXN_OP', 'WT_TXN_SHARED'],
         ['src/include/txn.h', 'src/include/txn_inline.h', 'src/txn/']),
diff --git a/src/third_party/wiredtiger/dist/s_docs b/src/third_party/wiredtiger/dist/s_docs
index 92dc6fd1acc..0f74d850711 100755
--- a/src/third_party/wiredtiger/dist/s_docs
+++ b/src/third_party/wiredtiger/dist/s_docs
@@ -124,7 +124,7 @@ valid_build()
 	}
 	classf=`ls ../docs/struct___* 2>/dev/null`
 	for c in $classf; do
-		echo "$c: Add class to PREDEFINED in src/docs/Doxyfile, then remove docs/*.{html,js} and rebuild"
+		echo "$c: Add class to PREDEFINED in src/docs/$doxyfile, then remove docs/*.{html,js} and rebuild"
 
 	done
 }
@@ -152,7 +152,7 @@ build()
 	# by swig does not have named arguments, but we want to document them
 	# as if they do.
 	(cd ../src/docs &&
-	    (eval cat Doxyfile $filter ; cat <<EOF
+	    (eval cat $doxyfile $filter ; cat <<EOF
 QUIET=YES
 EOF
 ) | doxygen -
@@ -189,6 +189,16 @@ EOF
 	fi
 }
 
+# Do not build the documentation if doxygen version is not compatible.
+v=$(doxygen --version)
+case "$v" in
+    1.8.17) doxyfile="Doxyfile";;
+    1.9.*) doxyfile="Doxyfile.9";;
+    *)
+        echo "$0 skipped: unsupported version of doxygen: $v, not 1.8.17 or 1.9.XX"
+        exit 0
+esac
+
 clean=0
 additional_languages=1
 filter="|sed '/PROJECT_BRIEF/s,=.*,=\"$WIREDTIGER_VERSION\",'"
@@ -200,7 +210,7 @@ while :
 		shift;;
 	-l)	# Generate the top-level landing page in ../docs/top
 		filter="$filter| sed '/GENERATE_MAN/s,=.*,=NO,';"
-		filter="$filter cat top/Doxyfile"
+		filter="$filter cat top/$doxyfile"
 		additional_languages=0
 		shift;;
 	-p)	# Generate PDFs
@@ -240,13 +250,6 @@ if [ $e != 0 ]; then
     exit $e
 fi
 
-# Do not build the documentation if Doxygen version is not compatible.
-v=$(doxygen --version)
-if [ "$v" != "1.8.17" ]; then
-    echo "$0 skipped: unsupported version of doxygen"
-    exit 0
-fi
-
 # Build the documentation.
 build $clean
 
diff --git a/src/third_party/wiredtiger/examples/c/ex_all.c b/src/third_party/wiredtiger/examples/c/ex_all.c
index 3d597fec10d..ce57fe54623 100644
--- a/src/third_party/wiredtiger/examples/c/ex_all.c
+++ b/src/third_party/wiredtiger/examples/c/ex_all.c
@@ -845,15 +845,17 @@ transaction_ops(WT_SESSION *session_arg)
     {
         /*! [reset snapshot] */
         /*
-         * Resets snapshots for snapshot isolation transactions to update their existing snapshot.
-         * It raises an error when this API is used for isolation other than snapshot isolation
-         * mode.
+         * Get a new read snapshot for the current transaction. This is only permitted for
+         * transactions running with snapshot isolation.
          */
+        const char *value1, *value2; /* For the cursor's string value. */
         error_check(session->open_cursor(session, "table:mytable", NULL, NULL, &cursor));
         error_check(session->begin_transaction(session, "isolation=snapshot"));
         cursor->set_key(cursor, "some-key");
         error_check(cursor->search(cursor));
+        error_check(cursor->get_value(cursor, &value1));
         error_check(session->reset_snapshot(session));
+        error_check(cursor->get_value(cursor, &value2)); /* May be different. */
         error_check(session->commit_transaction(session, NULL));
         /*! [reset snapshot] */
     }
@@ -883,6 +885,21 @@ transaction_ops(WT_SESSION *session_arg)
     error_check(session->begin_transaction(session, NULL));
 
     {
+        /*! [hexadecimal timestamp] */
+        uint64_t ts;
+        /* 2 bytes for each byte converted to hexadecimal; sizeof includes the trailing nul byte */
+        char timestamp_buf[sizeof("commit_timestamp=") + 2 * sizeof(uint64_t)];
+
+        (void)snprintf(timestamp_buf, sizeof(timestamp_buf), "commit_timestamp=%x", 20u);
+        error_check(session->timestamp_transaction(session, timestamp_buf));
+
+        error_check(conn->query_timestamp(conn, timestamp_buf, "get=all_durable"));
+        ts = strtoull(timestamp_buf, NULL, 16);
+        /*! [hexadecimal timestamp] */
+        (void)ts;
+    }
+
+    {
         /*! [query timestamp] */
         char timestamp_buf[2 * sizeof(uint64_t) + 1];
 
diff --git a/src/third_party/wiredtiger/import.data b/src/third_party/wiredtiger/import.data
index ed0bac80db2..1e3ad6f130a 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": "41b2d937fca755df7eaf201bad9293535aed5f17"
+    "commit": "6bfcab58b39232366daf8448c0cba29b7f170042"
 }
diff --git a/src/third_party/wiredtiger/src/docs/arch-glossary.dox b/src/third_party/wiredtiger/src/docs/arch-glossary.dox
index 21b1734780b..d1d4be527f4 100644
--- a/src/third_party/wiredtiger/src/docs/arch-glossary.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-glossary.dox
@@ -75,7 +75,7 @@ they are used in other settings.
 <tr><td>page split<td>btree<td>the process of breaking up a large page in a Btree into multiple smaller pages.  This may occur with either leaf pages or internal pages.
 <tr><td>pthread<td>general<td>a thread implementation used on POSIX systems
 <tr><td>raw<td>schema<td>data as it appears on-disk, typically in a packed format.
-<tr><td>read timestamp<td>transactions<td>a timestamp that specifies what data should be visible.
+<tr><td>read timestamp<td>transactions<td>a timestamp that specifies the time for reading data and thus what data should be visible.
 <tr><td>recno<td>general<td>a 64 bit integer. When used as a key, the Btree is said to be a column store, and the keys are assigned incrementally by WiredTiger when new records are inserted.
 <tr><td>reconcile<td>general<td>convert the in-memory version of a page to a more compact form for file storage.
 <tr><td>recovery<td>general<td>a procedure used on opening WiredTiger whereby, starting at the last checkpoint written, log records are played back to bring the database up to date.
@@ -88,7 +88,7 @@ they are used in other settings.
 <tr><td>skip list<td>general<td>a variation of a sorted linked list that allows for faster (O(log(N))) searching. It is used in WiredTiger as a lock-free data structure for keys inserted on a page.
 <tr><td>spin lock<td>general<td>a simple locking algorithm that continually attempts to acquire a lock, appropriate for resources that are likely to be available and may be held for a short time.  This lock is CPU intensive while it is waiting.  Contrast with mutex
 <tr><td>split<td>btree<td>see page split
-<tr><td>stable timestamp<td>transactions<td>a connection-wide value, checkpoints will not include commits newer than this value.
+<tr><td>stable timestamp<td>transactions<td>a connection-wide value. Checkpoints will not include commits newer than this value.
 <tr><td>table<td>schema<td>an abstraction that allows one or more btrees to be used in a coordinated way, which is specified by the schema.  The table coordinates indices and column groups.
 <tr><td>thread<td>general<td>a thread of control.  WiredTiger uses pthreads for POSIX systems.
 <tr><td>thread group<td>general<td>a group of threads that perform a common task.  Eviction is performed by a thread group.
diff --git a/src/third_party/wiredtiger/src/docs/arch-index.dox b/src/third_party/wiredtiger/src/docs/arch-index.dox
index 991bf7ff414..4abc17daf63 100644
--- a/src/third_party/wiredtiger/src/docs/arch-index.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-index.dox
@@ -138,6 +138,7 @@ of the documentation.
     - @ref arch-session
     - @ref arch-cursor
     - @ref arch-transaction
+    - @ref arch-timestamp
     - @ref arch-snapshot
     - @ref arch-rts
 
@@ -196,6 +197,10 @@ of the documentation.
 - Transactions provide a powerful abstraction for multiple threads to
 operate on data concurrently.
 
+@subpage arch-timestamp
+- Timestamping and the timestamped data model is a facility for
+supporting distributed applications.
+
 @subpage arch-snapshot
 - Snapshots are implemented by storing transaction ids committed before
 the transaction started.
diff --git a/src/third_party/wiredtiger/src/docs/arch-snapshot.dox b/src/third_party/wiredtiger/src/docs/arch-snapshot.dox
index 4f9618f56b1..38eaa1cb864 100644
--- a/src/third_party/wiredtiger/src/docs/arch-snapshot.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-snapshot.dox
@@ -48,7 +48,7 @@ smallest transaction ID value found from the list of concurrent transactions.
 An example of building out the aforementioned components of a snapshot can be seen in the below figure. This figure illustrates constructing a snapshot for a transaction with
 ID \c 8. Consider that at the given time, the concurrent running transactions are \c 3, \c 5, \c 7, \c 8 and the global current transaction ID is \c 9.
 
-@plantuml_start{snapshot.png}
+@plantuml_start{snapshot.png }
 @startuml{snapshot.png}
 digraph g {
 graph [
diff --git a/src/third_party/wiredtiger/src/docs/arch-transaction.dox b/src/third_party/wiredtiger/src/docs/arch-transaction.dox
index c9272356717..4e4b83f1d19 100644
--- a/src/third_party/wiredtiger/src/docs/arch-transaction.dox
+++ b/src/third_party/wiredtiger/src/docs/arch-transaction.dox
@@ -143,6 +143,8 @@ minimum timestamp that a new operation can commit at.
 
 Only transactions running in snapshot isolation can run with timestamps.
 
+See @ref arch-timestamp for further discussion.
+
 @subsection Visibility
 
 The visibility of the transactions in WiredTiger considers both the operations' transaction ids and
@@ -164,7 +166,7 @@ has been successfully committed, the operation is guaranteed to survive restart.
 only survive across restart under checkpoint durability if it is included in the last successful
 checkpoint.
 
-@section Prepared Transactions
+@section arch-transaction-prepare Prepared Transactions
 
 WiredTiger introduces prepared transactions to meet the needs of implementing distributed
 transactions through two-phase commit. Prepared transactions only work under snapshot isolation.
diff --git a/src/third_party/wiredtiger/src/docs/backup.dox b/src/third_party/wiredtiger/src/docs/backup.dox
index 32ed55f76ab..f42e0a4cf31 100644
--- a/src/third_party/wiredtiger/src/docs/backup.dox
+++ b/src/third_party/wiredtiger/src/docs/backup.dox
@@ -1,12 +1,13 @@
 /*! @class doc_bulk_durability
 
-Bulk-loads are not commit-level durable, that is, the creation and
+Bulk loads are not commit-level durable, that is, the creation and
 bulk-load of an object will not appear in the database log files.\  For
 this reason, applications doing incremental backups after a full backup
-should repeat the full backup step after doing a bulk-load to make the
-bulk-load durable.\ In addition, incremental backups after a bulk-load
+should repeat the full backup step after doing a bulk load to make the
+bulk load durable.\ In addition, incremental backups after a bulk load
+(without an intervening full backup)
 can cause recovery to report errors because there are log records that
-apply to data files which don't appear in the backup.
+apply to data files which do not appear in the backup.
 
 */
 
diff --git a/src/third_party/wiredtiger/src/docs/checkpoint.dox b/src/third_party/wiredtiger/src/docs/checkpoint.dox
index 628e7865bc5..bf2b6fd4513 100644
--- a/src/third_party/wiredtiger/src/docs/checkpoint.dox
+++ b/src/third_party/wiredtiger/src/docs/checkpoint.dox
@@ -8,95 +8,99 @@ application or system failure without impacting performance (although
 the creation of each checkpoint is a relatively heavy-weight operation).
 See @ref durability for information on commit-level durability.
 
-Checkpoints with transactional logging enabled allow logging to remove
-older log files (if configured to do so) while still retaining
-commit-level durability and the ability to run recovery.
-
-A checkpoint is automatically created whenever a modified data source
-is closed.  Additionally, checkpoints of one or more data sources, or
-the entire database, can be explicitly created using the
-WT_SESSION::checkpoint method.  Checkpoints can also be scheduled
-periodically based on elapsed time or data size with the \c checkpoint
-configuration to ::wiredtiger_open.
+@section checkpoint_snapshot Checkpoints vs. snapshots
+
+Since the terms "checkpoint" and "snapshot" are widely used in this manual, a
+quick explanation of the difference: a checkpoint is an on-disk entity that
+captures the persistent state of some or all of the database, while a snapshot
+is a lightweight in-memory entity that captures the current state of pending
+updates in the cache.  Isolation refers to snapshots, because isolation is about
+runtime state and which updates can be seen by other threads' transactions as
+they run.  Durability refers to checkpoints, because durability is about on-disk
+persistence.  The two concepts are closely connected, of course; when a
+checkpoint is created the code involved uses a snapshot to determine which
+updates should and should not appear in the checkpoint.
+
+@section checkpoints Checkpoints
+
+A checkpoint is automatically created for each individual file whenever the last
+reference to a modified data source is closed.
+
+Checkpoints of the entire database can be explicitly created with the
+WT_SESSION::checkpoint method. Automatic database-wide checkpoints can be
+scheduled based on elapsed time or data size with the ::wiredtiger_open \c
+checkpoint configuration. In this mode of operation, an internal server thread
+is created to perform these checkpoints.
 
 All transactional updates committed before a checkpoint are made durable
 by the checkpoint, therefore the frequency of checkpoints limits the
 volume of data that may be lost due to application or system failure.
-<b>This guarantee has an exception:</b> If a crash occurs when a backup
-cursor is open, then the system will be restored to the most recent
-checkpoint prior to the opening of the backup cursor, even if later
-database checkpoints were completed.
-
-Data sources that are involved in an exclusive operation when the
-checkpoint starts, including bulk load, verify or salvage, will be skipped
-by the checkpoint.  Operations requiring exclusive access may fail with
-an \c EBUSY error if attempted during a checkpoint.
-
-When data sources are first opened, they are opened in the state of the
-most recent checkpoint taken on the file, in other words, updates after the
-most recent checkpoint will not appear in the data source.  If no
-checkpoint is found when the data source is opened, the data source will
-appear empty.
 
-@section checkpoint_server Automatic checkpoints
+Data sources that are involved in an exclusive operation when the checkpoint
+starts, including bulk load, upgrade or salvage, will be skipped by the
+checkpoint.
 
-WiredTiger will automatically checkpoint the entire database when the
-\c checkpoint configuration parameter to ::wiredtiger_open is set.  When
-this configuration is used, an internal server thread is created.
-
-The period between checkpoints can be defined either in seconds via \c
-wait, or, if logging is enabled, as the number of bytes written to the log
-since the last checkpoint via \c log_size, or both.  If both periods are
-defined then the checkpoint occurs as soon as either threshold has occurred
-and both are reset once the checkpoint is complete.  If using \c log_size,
-we recommend that the size selected be a multiple of the log file size for
-automatic log file removal purposes.
+When a data source is first opened, it appears in the same state it was in when
+it was most recently checkpointed. In other words, updates after the most recent
+checkpoint will not appear in the data source at checkpoint-level durability.
+If no checkpoint is found when the data source is opened, the data source will
+appear empty.
 
 @section checkpoint_cursors Checkpoint cursors
 
 Cursors are normally opened in the most recent version of a data source.
-However, a checkpoint configuration string may be provided
+However, the \c checkpoint configuration string may be provided
 to WT_SESSION::open_cursor, opening a read-only, static view of the
 data source.  This provides a limited form of time-travel, as the static
 view is not changed by subsequent checkpoints and will persist until
 the checkpoint cursor is closed. While it is not an error to set a read
 timestamp in a transaction including a checkpoint cursor, it also has no
-effect on the checkpoint cursor's behavior.
+effect on the data returned by the checkpoint cursor.
 
 @section checkpoint_naming Checkpoint naming
 
-Additionally, checkpoints that do not include LSM trees may optionally be
-given names by the application.  Because named checkpoints persist until
-discarded or replaced, they can be used to periodically snapshot data for
-later use.
-
-Checkpoints named by the application persist until explicitly discarded or
-the application creates a new checkpoint with the same name (which replaces
-the previous checkpoint of that name). If the previous checkpoint cannot be
-replaced, either because a cursor is reading from the previous checkpoint,
-or backups are in progress, the checkpoint will fail.
-
-Internal checkpoints (that is, checkpoints not named by the application)
-use the reserved name "WiredTigerCheckpoint".  Applications can open the
-most recent of these checkpoints by specifying "WiredTigerCheckpoint"
-as the checkpoint name to WT_SESSION::open_cursor.   Creating a new
-internal checkpoint drops all previous internal checkpoints, if
-possible; if a previous internal checkpoint cannot be dropped for any
-reason, the checkpoint will ignore the previous checkpoint and continue.
-Subsequent checkpoints will drop those ignored checkpoints when it
-becomes possible.
-
-The \c -c option to the \c wt command line utility \c list command will
-list a data source's checkpoints, with time stamp, in a human-readable
-format.
+Checkpoints that do not include LSM trees may optionally be given names by the
+application.  Checkpoints named by the application persist until explicitly
+discarded or replaced with a new checkpoint by the same name.  (If an
+application attempts to replace an existing checkpoint, and it cannot be
+removed, either because a cursor is reading from the previous checkpoint, or
+because backups are in progress, the new checkpoint will fail and the previous
+checkpoint will remain.) Because named checkpoints persist until discarded or
+replaced, they can be used to save the state of the data for later use.
+
+Internal checkpoints, that is, checkpoints not named by the application, use the
+reserved name \c WiredTigerCheckpoint. (All checkpoint names beginning with this
+string are reserved.) Applications can open the most recent of these checkpoints
+by specifying \c WiredTigerCheckpoint as the checkpoint name to
+WT_SESSION::open_cursor.
+
+\warning
+Applications wanting a consistent view of the data in two separate tables must
+either use named checkpoints or explicitly control when checkpoints are taken,
+as there is a race between opening the default checkpoints in two different
+tables and a checkpoint operation replacing the default checkpoint in one of
+those tables.
+
+The \c -c option to the \c wt command line utility \c list command will list a
+data source's checkpoints, with time stamp, in a human-readable format.
+
+@section checkpoint_backup Checkpoint durability and backups
+
+Backups are done using backup cursors (see @ref backup for more information).
+
+\warning
+When applications are using checkpoint-level durability, checkpoints taken while
+a backup cursor is open are not durable. That is, if a crash occurs when a
+backup cursor is open, then the system will be restored to the most recent
+checkpoint prior to the opening of the backup cursor, even if later database
+checkpoints were completed.
 
 @section checkpoint_compaction Checkpoints and file compaction
 
 Checkpoints share file blocks, and dropping a checkpoint may or may not
 make file blocks available for re-use, depending on whether the dropped
-checkpoint contained the last reference to a file block.
-Because checkpoints named by the application are not discarded until
-explicitly discarded or replaced, they may prevent WT_SESSION::compact
-from accomplishing anything due to shared file blocks.
+checkpoint contained the last reference to those file blocks.  Because named
+checkpoints are not discarded until explicitly discarded or replaced, they may
+prevent WT_SESSION::compact from reducing file size due to shared file blocks.
 
- */
+*/
diff --git a/src/third_party/wiredtiger/src/docs/cursors.dox b/src/third_party/wiredtiger/src/docs/cursors.dox
index ba7d603ad13..5616e6b3a80 100644
--- a/src/third_party/wiredtiger/src/docs/cursors.dox
+++ b/src/third_party/wiredtiger/src/docs/cursors.dox
@@ -41,39 +41,6 @@ which are the values of the index), the data can be read from the index
 without accessing any column groups.  See @ref schema_index_projections for
 more information.
 
-@section cursors_transactions Cursors and Transactions
-
-If there is a transaction active in a session, cursors operate in the
-context of that transaction.  Reads performed while a transaction is
-active inherit the isolation level of the transaction, and updates
-performed within a transaction are made durable by calling
-WT_SESSION::commit_transaction, or discarded by calling
-WT_SESSION::rollback_transaction.
-
-If no transaction is active, cursor reads are performed at the isolation
-level of the session, set with the \c isolation configuration key to
-WT_CONNECTION::open_session and successful updates are automatically
-committed before the update operation completes.
-
-Any operation that consists of multiple related updates should be
-enclosed in an explicit transaction to ensure that the updates are
-applied atomically.
-
-At \c snapshot (the default) or \c read-committed isolation levels,
-committed changes from concurrent transactions become visible when no
-cursor is positioned.  In other words, at these isolation levels, all
-cursors in a session read from a stable snapshot while any cursor in the
-session remains positioned. A call to WT_CURSOR::next or WT_CURSOR::prev
-on a positioned cursor will not update the snapshot.
-
-Cursor positions survive transaction boundaries, unless a transaction
-is rolled back. When a transaction is rolled-back either implicitly
-or explicitly, all cursors in the session are reset as if the
-WT_CURSOR::reset method was called, discarding any cursor position as
-well as any key and value.
-
-See @ref transactions for more information.
-
 @section cursors_eviction Cursors and Eviction
 
 Cursor positions hold resources that can inhibit the eviction of memory
diff --git a/src/third_party/wiredtiger/src/docs/durability.dox b/src/third_party/wiredtiger/src/docs/durability.dox
index 5108b4560b5..e34f44b11b1 100644
--- a/src/third_party/wiredtiger/src/docs/durability.dox
+++ b/src/third_party/wiredtiger/src/docs/durability.dox
@@ -1,45 +1,76 @@
 /*! @page durability Commit-level durability
 
-WiredTiger supports checkpoint durability by default, and optionally
-commit-level durability when logging is enabled. In most applications,
-commit-level durability impacts performance more than checkpoint
-durability; checkpoints offer basic operation durability across
-application or system failure without impacting performance (although
-the creation of each checkpoint is a relatively heavy-weight operation).
-See @ref checkpoint for information on checkpoint durability.
-
-Commit-level durability is implemented using a write-ahead log and is
-enabled using the \c log=(enabled) configuration to ::wiredtiger_open.
-When logging is enabled, WiredTiger writes records to the log for each
-transaction.
-
-Transactions define which updates are made durable together; see
-@ref transactions for details.  By default, log records are buffered in memory
-when written by WT_SESSION::commit_transaction.  See
-@ref durability_group_commit for information about durability options.
+The next level of WiredTiger transactional application involves adding
+commit-level durability for data modifications. As described in @ref checkpoint,
+WiredTiger supports checkpoint durability by default. Commit-level durability
+requires additional configuration.
+
+@section commit_durability_enable Enabling commit-level durability
+
+To enable commit-level durability, pass the \c log=(enabled)
+configuration string to ::wiredtiger_open.
+This gives all objects opened in the database commit-level durability.
+The transactional API does not otherwise change.
+
+It is possible to enable commit-level durability for some database
+objects and not others.
+To do this, one must pass \c log=(enabled) to ::wiredtiger_open and
+then pass \c log=(enabled=false) to WT_SESSION::create for the objects
+that should continue to use checkpoint durability.
+(Doing the converse is not supported, that is,
+enabling logging on some tables while leaving the global switch turned
+off.)
+
+\warning
+Making commits to both checkpoint-durable and commit-durable objects in the same
+transaction requires caution: if the system crashes before another checkpoint is
+taken, any such transaction will be torn, only the commit-durable part of it
+will remain and the rest will be lost. In most cases this is undesirable,
+however, this combination can be usefully leveraged to create application-level
+write-ahead logs and is therefore explicitly supported.
+
+While this is rarely useful, object logging can be toggled during application restart
+(in other words, logging can be enabled for a table previously created or used
+with logging disabled, and vice-versa). Log records found during recovery are
+applied to the table, regardless of whether logging is currently configured for
+the table.
+
+@section commit_durability_logs Commit-level durability and logs
+
+Commit-level durability is implemented using a write-ahead log.
+When logging is enabled for an object, WiredTiger writes a record to
+the log for each update operating on the object.
+Transactions group updates, and in keeping with the principle of
+atomicity each transaction's updates become durable when the
+transaction is committed.
+
+By default, log records are buffered in memory and not flushed to disk
+immediately, even when committed; groups of transactions are flushed
+together.
+(See @ref durability_group_commit.)
+It is possible to flush transactions to disk more aggressively if
+desired.
+See @ref durability_flush_config.
+
+@section durability_recovery Recovery
 
 When the transactional log is enabled, calling ::wiredtiger_open
-automatically performs a recovery step when opening the database that
-applies whatever changes from the log are required to bring the database
-up to date with the most recent transactional state.  This recovery step
+automatically performs a recovery step when opening the database.
+This rolls the log forward; that is, it
+reapplies whatever changes from the log are required to bring the database
+up to date with the most recent transactional state.
+
+This recovery step
 may require extensions be available when it runs (for example, collators
-and compression).  Therefore, applications doing recovery must configure
+and compression).
+Therefore, applications using commit-level durability must configure
 extensions with the \c extensions keyword to ::wiredtiger_open consistently
 whenever re-opening the database.
 
-Recovery is required after the failure of any thread of control in the
-application, where the failed thread might have been executing inside
-of the WiredTiger library or open WiredTiger handles have been lost.  In
-most applications, if any thread of control exits unexpectedly, the
-application will close and re-open the database.
-
 @section durability_checkpoint Checkpoints
 
-Checkpoints of the database should still be performed periodically when
-commit-level durability is configured, either explicitly from the
-application or periodically based on elapsed time or data size with the
-\c checkpoint configuration to ::wiredtiger_open.
-
+When using commit-level durability one should still perform
+checkpoints of the database.
 Database checkpoints are necessary for two reasons: First, log files can
 only be removed after a checkpoint completes, and so the frequency of
 checkpoints determines the disk space required by log files.  Second,
@@ -47,36 +78,43 @@ checkpoints bound the time required for recovery to complete after
 application or system failure by limiting the log records that need to
 be processed.
 
-@section durability_backup Backups
+Checkpoints can be done either explicitly by the application or periodically
+based on elapsed time or data size with the \c checkpoint configuration to
+::wiredtiger_open.  The period between checkpoints can be defined in seconds via
+\c wait, as the number of bytes written to the log since the last checkpoint via
+\c log_size, or both.  If both periods are defined then the checkpoint occurs as
+soon as either threshold has occurred and both are reset once the checkpoint is
+complete.  If using \c log_size to scheduled automatic checkpoints, we recommend
+the size selected be a multiple of the physical size of the underlying log file
+to more easily support automatic log file removal.
 
-With logging enabled, partial backups (backups where not all of the
-database objects are copied), may result in error messages during
-recovery, because data files referenced in the logs might not be found.
-Applications should either copy all objects and log files if
-commit-level durability of the copied database is required, or
-alternatively, copy only selected objects when backing up and not copy
-log files at all, then fall back to checkpoint durability when switching
-to the backup.
+@section durability_backup Backups
 
-@section durability_bulk Bulk loads
+Backups are done using backup cursors (see @ref backup for more information).
 
-@copydoc doc_bulk_durability
+With logging enabled, partial backups (backups where not all of the database
+objects are copied) may result in error messages during recovery, because data
+files referenced in the logs might not be found.  Applications should either
+copy all objects and log files if commit-level durability of the copied database
+is required, or alternatively, copy only selected objects when backing up and
+not copy log files at all, then fall back to checkpoint durability when
+switching to the backup.
 
-@section durability_archiving Log file archival
+@section durability_archiving Log file archival and removal
 
 WiredTiger log files are named "WiredTigerLog.[number]" where "[number]"
-is a 10-digit value, for example, WiredTigerLog.0000000001".  The log
+is a 10-digit value, for example WiredTigerLog.0000000001".  The log
 file with the largest number in its name is the most recent log file
 written.  The log file size can be set using the \c log configuration
 to ::wiredtiger_open.
 
-By default, WiredTiger automatically removes log files no longer
-required for recovery.  Applications wanting to archive log files
-instead must disable log file removal using the \c log=(remove=false)
-configuration to ::wiredtiger_open.
+By default, WiredTiger automatically removes log files no longer required for
+recovery. Applications wanting to archive log files instead (for example, to
+support catastrophic recovery), must disable log file removal using the
+::wiredtiger_open \c log=(remove=false) configuration.
 
 Log files may be removed or archived after a checkpoint has completed,
-as long as there's not a backup in progress.  When performing @ref
+as long as there is no backup in progress.  When performing @ref
 backup_incremental, WT_SESSION::truncate can be used to remove log files
 after completing each incremental backup.
 
@@ -84,11 +122,21 @@ Immediately after the checkpoint has completed, only the most recent log file
 is needed for recovery, and all other log files can be removed or archived.
 Note that there must always be at least one log file for the database.
 
-Open log cursors prevents WiredTiger from automatically removing log files.
+@section log_cursors Log cursors
+
+Applications can independently read and write WiredTiger log files for their own
+purposes (for example, inserting debugging records), using the standard
+WiredTiger cursor interfaces. See @ref cursor_log for more information.
+
+Open log cursors prevent WiredTiger from automatically removing log files.
 Therefore, we recommend proactively closing log cursors when done with them.
 Applications manually removing log files should take care that no log cursors
-are opened in the log when removing files or errors may occur when trying
-to read a log record in a file that was removed.
+are opened in the log when removing files or errors may occur when trying to
+read a log record in a file that was removed.
+
+@section durability_bulk Bulk loads
+
+@copydoc doc_bulk_durability
 
 @section durability_tuning Tuning commit-level durability
 
diff --git a/src/third_party/wiredtiger/src/docs/introduction.dox b/src/third_party/wiredtiger/src/docs/introduction.dox
index 887814c57ff..15baaced52c 100644
--- a/src/third_party/wiredtiger/src/docs/introduction.dox
+++ b/src/third_party/wiredtiger/src/docs/introduction.dox
@@ -10,7 +10,7 @@ and storage of column subsets) and log-structured merge trees (LSM), for sustain
 under random insert workloads.
 
 WiredTiger includes ACID transactions with standard isolation levels and durability at both
-checkpoint and fine-grained granularity.
+checkpoint and commit-level granularity.
 
 WiredTiger can be used as a simple key/value store, but also has a complete schema layer,
 including indices and projections.
@@ -30,8 +30,8 @@ For more information about building and installing WiredTiger, see:
 
 For more information about writing WiredTiger applications, see:
 
-- @ref wt "WiredTiger API reference manual"
 - @subpage programming
+- @ref wt "WiredTiger API reference manual"
 
 For more information about administrating WiredTiger databases, see:
 
diff --git a/src/third_party/wiredtiger/src/docs/programming.dox b/src/third_party/wiredtiger/src/docs/programming.dox
index 731abc8d60a..2fa0cd0737a 100644
--- a/src/third_party/wiredtiger/src/docs/programming.dox
+++ b/src/third_party/wiredtiger/src/docs/programming.dox
@@ -9,23 +9,37 @@ value.  Tables may optionally have an associated schema, splitting the
 value into a set of columns.  Tables may also have associated indices,
 each of which is ordered by one or more columns.
 
-<h2>Using the API</h2>
+<h2>The WiredTiger API</h2>
 - @subpage basic_api
 - @subpage config_strings
 - @subpage cursors
-- @subpage transactions
+- @subpage schema
 - @subpage error_handling
-- @subpage message_handling
-- @subpage verbose_messaging
+
+<h2>Transactions</h2>
+- @subpage transactions
+- @subpage transactions_api
+- @subpage checkpoint
+- @subpage durability
+- @subpage timestamp_model
+- @subpage timestamp_global_api
+- @subpage timestamp_txn_api
+- @subpage timestamp_prepare
+- @subpage timestamp_roundup
+- @subpage timestamp_misc
+- @subpage explain_acid
+- @subpage explain_durability
+- @subpage explain_isolation
 
 <h2>Storage options</h2>
-- @subpage schema
 - @subpage lsm
 - @subpage file_formats
 - @subpage compression
 - @subpage encryption
 
 <h2>Programming notes</h2>
+- @subpage message_handling
+- @subpage verbose_messaging
 - @subpage threads
 - @subpage namespace
 - @subpage readonly
@@ -34,10 +48,8 @@ each of which is ordered by one or more columns.
 <h2>Advanced topics</h2>
 - @subpage backup
 - @subpage compact
-- @subpage checkpoint
-- @subpage eviction
-- @subpage durability
 - @subpage in_memory
+- @subpage eviction
 - @subpage cursor_join
 - @subpage cursor_log
 - @subpage operation_tracking
diff --git a/src/third_party/wiredtiger/src/docs/spell.ok b/src/third_party/wiredtiger/src/docs/spell.ok
index 63b7b6bfc36..d1f453ca677 100644
--- a/src/third_party/wiredtiger/src/docs/spell.ok
+++ b/src/third_party/wiredtiger/src/docs/spell.ok
@@ -56,6 +56,7 @@ Encryptors
 FSTREAM
 Facebook
 Facebook's
+FIXME
 FlameGraph
 FlameGraphs
 FlexeLint
@@ -127,6 +128,7 @@ SYSV
 Sanitizer
 Seward's
 SiH
+Timestamping
 TSC
 TXID
 TXT
@@ -635,7 +637,9 @@ thang
 tid
 timeline
 timelines
+timespan
 timestamp
+timestamping
 timestamps
 toc
 todo
diff --git a/src/third_party/wiredtiger/src/docs/transactions.dox b/src/third_party/wiredtiger/src/docs/transactions.dox
index 7c1408a635c..6cf399075bf 100644
--- a/src/third_party/wiredtiger/src/docs/transactions.dox
+++ b/src/third_party/wiredtiger/src/docs/transactions.dox
@@ -1,288 +1,50 @@
-/*! @page transactions Transactions
-
-@section transactions_acid ACID properties
-
-Transactions provide a powerful abstraction for multiple threads to
-operate on data concurrently because they have the following properties:
-
-- Atomicity: all or none of a transaction is completed.
-- Consistency: if each transaction maintains some property when considered
-  separately, then the combined effect of executing the transactions
-  concurrently will maintain the same property.
-- Isolation: developers can reason about transactions as if they run
-  single-threaded.
-- Durability: once a transaction commits, its updates cannot be lost.
-
-WiredTiger supports transactions with the following caveats to the ACID
-properties:
-
-- the maximum level of isolation supported is snapshot isolation and all updates must be done at
-  snapshot isolation. See @ref transaction_isolation for more details.
-- transactional updates are made durable by a combination of checkpoints
-  and logging.  See @ref checkpoint for information on checkpoint durability
-  and @ref durability for information on commit-level durability.
-
-@section transactions_api Transactional API
-
-In WiredTiger, transaction operations are methods off the WT_SESSION
-class.
-
-Applications call WT_SESSION::begin_transaction to start a new transaction.
-Operations subsequently performed using that WT_SESSION handle, including
-operations on any cursors open in that WT_SESSION handle (whether opened
-before or after the WT_SESSION::begin_transaction call), are part of the
-transaction and their effects committed by calling
-WT_SESSION::commit_transaction, or discarded by calling
-WT_SESSION::rollback_transaction. Applications that use
-@ref transaction_timestamps can utilize the WT_SESSION::prepare_transaction API
-as a basis for implementing a two phase commit protocol.
-
-If WT_SESSION::commit_transaction returns an error for any reason, the
-transaction was rolled back, not committed.
-
-When transactions are used, data operations can encounter a conflict and
-fail with the ::WT_ROLLBACK error.  If this error occurs, transactions
-should be rolled back with WT_SESSION::rollback_transaction and the
-operation retried.
-
-The WT_SESSION::rollback_transaction method implicitly resets all
-cursors in the session as if the WT_CURSOR::reset method was called,
-discarding any cursor position as well as any key and value.
-
-@snippet ex_all.c transaction commit/rollback
-
-Applications can call WT_SESSION::reset_snapshot to reset snapshots for
-snapshot isolation transactions to update their existing snapshot. It raises
-an error when this API is used for isolation other than snapshot isolation mode
-or when the session has performed any write operations.
-This API internally releases the current snapshot and gets the new running
-transactions snapshot to avoid pinning the content in the database that is no
-longer needed. Applications that don't use read_timestamp for the search may
-see different results compared to earlier with the updated snapshot.
-
-@snippet ex_all.c reset snapshot
-
-@section transactions_implicit Implicit transactions
-
-If a cursor is used when no explicit transaction is active in a session,
-reads are performed at the isolation level of the session, set with the
-\c isolation key to WT_CONNECTION::open_session, and successful updates
-are automatically committed before the update operation returns.
-
-Any operation consisting of multiple related updates should be enclosed
-in an explicit transaction to ensure the updates are applied atomically.
-
-If an implicit transaction successfully commits, the cursors in the
-WT_SESSION remain positioned.  If an implicit transaction fails, all
-cursors in the WT_SESSION are reset, as if WT_CURSOR::reset were called,
-discarding any position or key/value information they may have.
-
-See @ref cursors_transactions for more information.
-
-@section transactions_concurrency Concurrency control
-
-WiredTiger uses optimistic concurrency control algorithms.  This avoids
-the bottleneck of a centralized lock manager and ensures transactional
-operations do not block: reads do not block writes, and vice versa.
-
-Further, writes do not block writes, although concurrent transactions
-updating the same value will fail with ::WT_ROLLBACK.  Some applications
-may benefit from application-level synchronization to avoid repeated
-attempts to rollback and update the same value.
-
-Operations in transactions may also fail with the ::WT_ROLLBACK error if
-some resource cannot be allocated after repeated attempts.  For example, if
-the cache is not large enough to hold the updates required to satisfy
-transactional readers, an operation may fail and return ::WT_ROLLBACK.
-
-@section transaction_isolation Isolation levels
-
-WiredTiger supports <code>read-uncommitted</code>,
-<code>read-committed</code> and <code>snapshot</code> isolation levels; the default isolation
-level is <code>snapshot</code>, and all updates must be done at snapshot isolation.
-
-- <code>read-uncommitted</code>:
-Transactions can see changes made by other transactions before those
-transactions are committed.  Dirty reads, non-repeatable reads and
-phantoms are possible.
-
-- <code>read-committed</code>:
-Transactions cannot see changes made by other transactions before those
-transactions are committed.  Dirty reads are not possible;
-non-repeatable reads and phantoms are possible.  Committed changes from
-concurrent transactions become visible when no cursor is positioned in
-the read-committed transaction.
-
-- <code>snapshot</code>:
-Transactions read the versions of records committed before the transaction
-started.  Dirty reads and non-repeatable reads are not possible; phantoms
-are possible.<br><br>
-Snapshot isolation is a strong guarantee, but not equivalent to a
-single-threaded execution of the transactions, known as serializable
-isolation.  Concurrent transactions T1 and T2 running under snapshot
-isolation may both commit and produce a state that neither (T1 followed
-by T2) nor (T2 followed by T1) could have produced, if there is overlap
-between T1's reads and T2's writes, and between T1's writes and T2's
-reads.
-
-The transaction isolation level can be configured on a per-transaction
-basis:
-
-@snippet ex_all.c transaction isolation
-
-Additionally, the default transaction isolation can be configured and
-re-configured on a per-session basis:
-
-@snippet ex_all.c session isolation configuration
-
-@snippet ex_all.c session isolation re-configuration
-
-@section transaction_timestamps Application-specified Transaction Timestamps
-
-@subsection timestamp_overview Timestamp overview
-
-Some applications have their own notion of time, including an expected commit
-order for transactions that may be inconsistent with the order assigned by
-WiredTiger. We assume applications can represent their notion of a timestamp
-as an unsigned 64-bit integral value that generally increases over time. For
-example, a counter could be incremented to generate transaction timestamps,
-if that is sufficient for the application.
-
-Applications can assign explicit commit timestamps to transactions, then read
-"as of" a timestamp. The timestamp mechanism operates in parallel with
-WiredTiger's internal transaction ID management. It is recommended that once
-timestamps are in use for a particular table, all subsequent updates also use
-timestamps.
-
-@subsection timestamp_transactions Using transactions with timestamps
-
-Applications that use timestamps will generally provide a timestamp at
-WT_SESSION::transaction_commit that will be assigned to all updates that are
-part of the transaction. WiredTiger also provides the ability to set a different
-commit timestamp for different updates in a single transaction. This can
-be done by calling WT_SESSION::timestamp_transaction repeatedly to set a new
-commit timestamp between a set of updates for the current transaction. This
-gives the ability to commit updates with different read "as of" timestamps in a
-single transaction.
-
-Setting a read timestamp in WT_SESSION::begin_transaction forces a transaction
-to run at snapshot isolation and ignore any commits with a newer timestamp.
-
-Commit timestamps cannot be set in the past of any read timestamp that has
-been used.  This is enforced by assertions in diagnostic builds, if
-applications violate this rule, data consistency can be violated.
-
-The commits to a particular data item must be performed in timestamp
-order.  If applications violate this rule, data consistency can be
-violated. Committing an update without a timestamp truncates the update's
-timestamp history and limits repeatable reads: no earlier version of the
-update will be returned regardless of the setting of the read timestamp.
-
-The WT_SESSION::prepare_transaction API is designed to be used in conjunction
-with timestamps and assigns a prepare timestamp to the transaction, which will
-be used for visibility checks until the transaction is committed or aborted.
-Once a transaction has been prepared the only other operations that can be
-completed are WT_SESSION::commit_transaction or
-WT_SESSION::rollback_transaction. The WT_SESSION::prepare_transaction API only
-guarantees that transactional conflicts will not cause the transaction to
-rollback - it does not guarantee that the transactions updates are durable. If
-a read operation encounters an update from a prepared transaction a
-WT_PREPARE_CONFLICT error will be returned indicating that it is not possible
-to choose a version of data to return until a prepared transaction is resolved,
-it is reasonable to retry such operations.
-
-Durability of the data updates performed by a prepared transaction, on tables
-configured with log=(enabled=false), can be controlled by specifying a durable
-timestamp during WT_SESSION::commit_transaction. Checkpoint will consider the
-durable timestamp, instead of commit timestamp for persisting the data updates.
-If the durable timestamp is not specified, then the commit timestamp will be
-considered as the durable timestamp.
-
-There are a number of constraints around assigning timestamps for running
-transactions - the table below summarizes those constraints:
-
-| API     | Prepared | Constraint | Enforced | Description |
-|---------|----------|------------|----------|-------------|
-| Prepare | During | prepare_timestamp >= stable_timestamp | Y | None |
-| Commit  | No | commit_timestamp > stable_timestamp | Y | None |
-| Commit  | Yes | commit_timestamp >= prepare_timestamp | Y | The commit timestamp may be older than the oldest timestamp at the time of commit. |
-| Commit  | Yes | durable_timestamp > stable_timestamp | Y | None |
-| Commit  | Yes | durable_timestamp != 0 \|\| commit_timestamp > stable_timestamp | N | If no durable timestamp is given when committing a prepared transaction, the commit timestamp must be greater than the stable timestamp. |
-
-@subsection timestamp_roundup Automatic rounding of timestamps
-Applications setting timestamps for a transaction have to comply with the
-constraints based on the global timestamp state. In order to be compliant with
-the constraints applications need to query the global timestamp state and
-check their timestamps for compliance and adjust timestamps if required.
-To simplify the burden on applications related to rounding up timestamps
-WiredTiger supports automatic rounding of timestamps in some scenarios.
-
-Applications can configure
-<code>roundup_timestamps=(prepared=true,read=true)</code> with
-WT_SESSION::begin_transaction.
-
-The configuration <code>roundup_timestamps=(prepared=true)</code> will be valid
-only for prepared transactions. It indicates that the prepare timestamp could be
-rounded up to the oldest timestamp, if the prepare timestamp is less than the
-oldest timestamp. This setting also indicates that the commit timestamp of the
-transaction could be rounded up to the prepare timestamp, if the commit
-timestamp is less than the prepare timestamp. Based on the timestamps values
-and constraints, enabling this configuration could result in only one of
-timestamps being rounded up. For example, for the timestamp values
-<code>prepare_timestamp=100, commit_timestamp=300, oldest_timestamp=200</code>
-with configuration <code>roundup_timestamps=(prepared=true)</code> only the
-prepare timestamp will be rounded up to the oldest timestamp and the commit
-timestamp will not be adjusted and the result will be
-<code>prepare_timestamp=200, commit_timestamp=300, oldest_timestamp=200</code>.
-For cases where both the prepare timestamp and the commit timestamp needs to be
-rounded up, first the prepare timestamp will be rounded to the oldest timestamp
-and then the commit timestamp will be rounded up to the new prepare timestamp.
-For example, for the timestamp values <code>prepare_timestamp=100,
-    commit_timestamp=150, oldest_timestamp=200</code> with configuration
-    <code>roundup_timestamps=(prepared=true)</code>, the prepare timestamp is
-    rounded up to the oldest timestamp, as part of the
-    WT_SESSION::prepare_transaction, as <code>prepare_timestamp=200</code> and
-    subsequently as part of WT_SESSION::commit_transaction, the commit
-    timestamp is rounded up to the new prepare timestamp as
-    <code>commit_timestamp=200</code>.
-
-Configuring <code>roundup_timestamps=(read=true)</code> causes the read
-timestamp to be rounded up to the oldest timestamp, if the read timestamp is
-greater than the oldest timestamp no change will be made.
-
-@subsection timestamp_connection Managing global timestamp state
-
-Applications that use timestamps need to manage some global state in order
-to allow WiredTiger to clean up old updates, and not make new updates durable
-until it is safe to do so. That state is managed using the
-WT_CONNECTION::set_timestamp API.
-
-Setting an oldest timestamp in WT_CONNECTION::set_timestamp indicates that
-future read timestamps will be at least as recent as the oldest timestamp, so
-WiredTiger can discard history before the specified point.  It is critical
-that the oldest timestamp update frequently or the cache can become full of
-updates, reducing performance.
-
-Setting a stable timestamp in WT_CONNECTION::set_timestamp indicates a
-known stable location that is sufficient for durability.  During a checkpoint
-the state of a table will be saved only as of the stable timestamp.  Newer
-updates after that stable timestamp will not be included in the checkpoint.
-That can be overridden in the call to WT_SESSION::checkpoint.  It is expected
-that the stable timestamp is updated frequently. Setting a stable location
-provides the ability, if needed, to rollback to this location by placing a call
-to WT_CONNECTION::rollback_to_stable. With the rollback, however, WiredTiger
-does not automatically reset the maximum commit timestamp it is tracking. The
-application should explicitly do so by setting a commit timestamp in
-WT_CONNECTION::set_timestamp.
-
-| Timestamp | Description | Constraint |
-|-----------|-------------|------------|
-| all_committed | The oldest timestamp at which all previous write transactions have committed. | |
-| last_checkpoint | The point at which the last checkpoint ran. If no checkpoint has run it's value will be 0. | last_checkpoint <= stable timestamp |
-| oldest | Point in time readers cannot be created using a timestamp older than the oldest timestamp, as explained above modification history is discarded prior to the oldest timestamp. This timestamp can be set via the API. | 0 <= oldest <= stable |
-| oldest_reader | The timestamp of the oldest currently active read transaction, if there is no current read transaction then querying for the oldest_reader with WT_CONNECTION::query_timestamp will return WT_NOTFOUND. | |
-| pinned | Minimum of the oldest_reader and oldest timestamp. | |
-| recovery | The stable timestamp used, if any, in the most recent checkpoint prior to the last shutdown. | |
-| stable | Any active transaction with a commit timestamp less than or equal to the current stable timestamp will not be able to modify data, except in the instance of prepared transactions. This timestamp can be set via the API. | stable >= oldest |
-
- */
+/*! @page transactions Transactional applications
+
+WiredTiger offers standard ACID-style transaction support where operations are
+done at snapshot isolation and subsequently become durable. (Readers not
+already familiar with these concepts may wish to see @ref explain_acid for a brief
+discussion of ACID and @ref explain_isolation for a brief discussion of isolation
+levels.)
+
+There are three approaches to writing transactional programs in WiredTiger:
+-# Applications supporting \b checkpoint-level durability, intended for
+applications with simple transactions where updates become durable when
+the last reference to the object is closed or at the next database checkpoint.
+
+-# Applications supporting \b commit-level durability, which extends checkpoint-level
+durability, adding logging to the database so updates are durable as
+soon as their transaction successfully commits.
+
+-# Applications using timestamps for fine-grained control of the database,
+extending commit-level durability. This allows applications to do things like
+enforce a transactional commit order, read historical data and define stability
+points for the entire database. Use of timestamps changes both the consistency
+and durability models.
+
+The first two approaches are relatively simple and have APIs which will be
+familiar to database developers. The principal difference is that in the second
+approach, applications may need to enclose operations in explicit transactional
+API calls and must additionally configure and manage the log files required for
+commit-level durability. The third approach is complex, has non-standard APIs,
+and requires more database knowledge to successfully build applications. The
+functionality and programmatic changes in each approach are additive. If this is
+your first database application, building a complex application by starting at
+the first approach and iterating to a complete application is recommended.
+
+We will discuss these approaches in order, from the simplest to the most
+complex.
+
+If this is your first WiredTiger application, please read @ref explain_durability
+for a discussion of WiredTiger durability models, so you can select the application
+architecture that's appropriate for your needs.
+
+\warning
+Recovery is the process of restoring the database to a consistent state after
+failure. Recovery is automatically performed by WiredTiger, as necessary, when a
+database is opened. Recovery is required after the failure of any thread of
+control in the application, where the failed thread might have been executing
+inside of the WiredTiger library or open WiredTiger handles have been lost. If
+any application thread of control exits unexpectedly while holding any database
+resources of any kind, the application should close and re-open the database.
+
+*/
diff --git a/src/third_party/wiredtiger/src/docs/tune-durability.dox b/src/third_party/wiredtiger/src/docs/tune-durability.dox
index 5350c617d3b..b8c62081362 100644
--- a/src/third_party/wiredtiger/src/docs/tune-durability.dox
+++ b/src/third_party/wiredtiger/src/docs/tune-durability.dox
@@ -14,7 +14,7 @@ required for this feature.
 By default, log records are written to an in-memory buffer before
 WT_SESSION::commit_transaction returns, giving highest performance but
 not ensuring durability.  The durability guarantees can be stricter but
-will impact performance.
+this will impact performance.
 
 If \c transaction_sync=(enabled=false) is configured to ::wiredtiger_open,
 log records may be buffered in memory, and only flushed to disk by
@@ -31,13 +31,13 @@ system's \c fsync call (of \c fdatasync if available) as each commit completes.
 
 If the value is set to \c dsync, the \c O_DSYNC or \c O_SYNC
 flag to the operating system's \c open call will be specified when the
-file is opened.  (The durability guarantee of the \c fsync and \c dsync
+file is opened.  (The durability guarantees of the \c fsync and \c dsync
 configurations are the same, and in our experience the \c open flags are
-slower, this configuration is only included for systems where that may
+slower; this configuration is only included for systems where that may
 not be the case.)
 
 If the value is set to \c none, the operating system's \c write call
-will be called as each commit completes but does not flush to disk.
+will be called as each commit completes but no explicit disk flush is made.
 This setting gives durability at the application level but not at
 the system level.
 
@@ -91,7 +91,8 @@ forces the data out via \c fsync.
 
 If \c sync=off is configured then this flush operation will force the
 logging subsystem to write any outstanding in-memory buffers to the
-file system before returning.
+operating system before returning, but not explicitly ask the OS to
+flush them.
 
  */
 
diff --git a/src/third_party/wiredtiger/src/docs/verbose-messaging.dox b/src/third_party/wiredtiger/src/docs/verbose-messaging.dox
index 314c57e1514..0afc65bbc25 100644
--- a/src/third_party/wiredtiger/src/docs/verbose-messaging.dox
+++ b/src/third_party/wiredtiger/src/docs/verbose-messaging.dox
@@ -1,4 +1,4 @@
-/*! @page verbose_messaging Verbose Messaging
+/*! @page verbose_messaging Verbose messaging
 
 As part of normal operation, WiredTiger will produce verbose messages
 around various events, actions and possible issues/errors. Verbose
diff --git a/src/third_party/wiredtiger/src/include/wiredtiger.in b/src/third_party/wiredtiger/src/include/wiredtiger.in
index 4b0934af0fc..3d0fbcd16c1 100644
--- a/src/third_party/wiredtiger/src/include/wiredtiger.in
+++ b/src/third_party/wiredtiger/src/include/wiredtiger.in
@@ -1718,20 +1718,16 @@ struct __wt_session {
 	 * greater than or equal to 1; default \c 0.}
 	 * @config{priority, priority of the transaction for resolving conflicts.  Transactions with
 	 * higher values are less likely to abort., an integer between -100 and 100; default \c 0.}
-	 * @config{read_before_oldest, allows the caller to specify a read timestamp less than the
-	 * oldest timestamp but newer than or equal to the pinned timestamp.  Cannot be set to true
-	 * while also rounding up the read timestamp.  See @ref transaction_timestamps., a boolean
-	 * flag; default \c false.}
 	 * @config{read_timestamp, read using the specified timestamp.  The supplied value must not
-	 * be older than the current oldest timestamp.  See @ref transaction_timestamps., a string;
+	 * be older than the current oldest timestamp.  See @ref timestamp_txn_api., a string;
 	 * default empty.}
 	 * @config{roundup_timestamps = (, round up timestamps of the transaction.  This setting
-	 * alters the visibility expected in a transaction.  See @ref transaction_timestamps., a set
-	 * of related configuration options defined below.}
-	 * @config{&nbsp;&nbsp;&nbsp;&nbsp;
-	 * prepared, applicable only for prepared transactions.  Indicates if the prepare timestamp
-	 * and the commit timestamp of this transaction can be rounded up.  If the prepare timestamp
-	 * is less than the oldest timestamp\, the prepare timestamp will be rounded to the oldest
+	 * alters the visibility expected in a transaction.  See @ref timestamp_roundup., a set of
+	 * related configuration options defined below.}
+	 * @config{&nbsp;&nbsp;&nbsp;&nbsp;prepared,
+	 * applicable only for prepared transactions.  Indicates if the prepare timestamp and the
+	 * commit timestamp of this transaction can be rounded up.  If the prepare timestamp is less
+	 * than the stable timestamp\, the prepare timestamp will be rounded to the stable
 	 * timestamp.  If the commit timestamp is less than the prepare timestamp\, the commit
 	 * timestamp will be rounded up to the prepare timestamp., a boolean flag; default \c
 	 * false.}
@@ -1761,13 +1757,17 @@ struct __wt_session {
 	 * @param session the session handle
 	 * @configstart{WT_SESSION.commit_transaction, see dist/api_data.py}
 	 * @config{commit_timestamp, set the commit timestamp for the current transaction.  The
-	 * supplied value must not be older than the first commit timestamp set for the current
-	 * transaction.  The value must also not be older than the current oldest and stable
-	 * timestamps.  See @ref transaction_timestamps., a string; default empty.}
-	 * @config{durable_timestamp, set the durable timestamp for the current transaction.  The
+	 * supplied value must not be older than the first commit timestamp already set for the
+	 * current transaction\, if any.  The value must also not be older than the current oldest
+	 * and stable timestamps.  A commit timestamp is required for the commit of a prepared
+	 * transaction.  If the prepare timestamp has been set (because the transaction has been
+	 * prepared)\, the commit timestamp must not be older than it.  See @ref timestamp_txn_api.,
+	 * a string; default empty.}
+	 * @config{durable_timestamp, set the durable timestamp for the current transaction.
+	 * Required for the commit of a prepared transaction\, and otherwise not permitted.  The
 	 * supplied value must not be older than the commit timestamp set for the current
-	 * transaction.  The value must also not be older than the current stable timestamp.  See
-	 * @ref transaction_timestamps., a string; default empty.}
+	 * transaction.  The value must also not be older than the current oldest and stable
+	 * timestamps.  See @ref timestamp_prepare., a string; default empty.}
 	 * @config{operation_timeout_ms, when non-zero\, a requested limit on the time taken to
 	 * complete operations in this transaction.  Time is measured in real time milliseconds from
 	 * the start of each WiredTiger API call.  There is no guarantee any operation will not take
@@ -1776,7 +1776,7 @@ struct __wt_session {
 	 * greater than or equal to 1; default \c 0.}
 	 * @config{sync, override whether to sync log records when the transaction commits\,
 	 * inherited from ::wiredtiger_open \c transaction_sync.  The \c off setting does not wait
-	 * for record to be written or synchronized.  The \c on setting forces log records to be
+	 * for records to be written or synchronized.  The \c on setting forces log records to be
 	 * written to the storage device., a string\, chosen from the following options: \c "off"\,
 	 * \c "on"; default empty.}
 	 * @configend
@@ -1802,8 +1802,9 @@ struct __wt_session {
 	 * @param session the session handle
 	 * @configstart{WT_SESSION.prepare_transaction, see dist/api_data.py}
 	 * @config{prepare_timestamp, set the prepare timestamp for the updates of the current
-	 * transaction.  The supplied value must not be older than any active read timestamps.  See
-	 * @ref transaction_timestamps., a string; default empty.}
+	 * transaction.  The supplied value must not be older than any active read timestamps\, must
+	 * not be older than the current stable timestamp\, and must not be newer than any commit
+	 * timestamps already set.  See @ref timestamp_prepare., a string; default empty.}
 	 * @configend
 	 * @errors
 	 */
@@ -1866,19 +1867,27 @@ struct __wt_session {
 	 * @param session the session handle
 	 * @configstart{WT_SESSION.timestamp_transaction, see dist/api_data.py}
 	 * @config{commit_timestamp, set the commit timestamp for the current transaction.  The
-	 * supplied value must not be older than the first commit timestamp set for the current
-	 * transaction.  The value must also not be older than the current oldest and stable
-	 * timestamps.  See @ref transaction_timestamps., a string; default empty.}
-	 * @config{durable_timestamp, set the durable timestamp for the current transaction.  The
-	 * supplied value must not be older than the commit timestamp set for the current
-	 * transaction.  The value must also not be older than the current stable timestamp.  See
-	 * @ref transaction_timestamps., a string; default empty.}
+	 * supplied value must not be older than the first commit timestamp already set for the
+	 * current transaction\, if any.  The value must also not be older than the current oldest
+	 * and stable timestamps.  A commit timestamp is required for the commit of a prepared
+	 * transaction.  If the prepare timestamp has already been set\, the commit timestamp must
+	 * not be older than it.  See @ref timestamp_txn_api., a string; default empty.}
+	 * @config{durable_timestamp, set the durable timestamp for the current transaction.
+	 * Required for the commit of a prepared transaction\, and otherwise not permitted.  Can
+	 * only be set once the current transaction has been prepared\, and a commit timestamp has
+	 * been set.  The supplied value must not be older than the commit timestamp.  The value
+	 * must also not be older than the current oldest and stable timestamps.  See @ref
+	 * timestamp_prepare., a string; default empty.}
 	 * @config{prepare_timestamp, set the prepare timestamp for the updates of the current
-	 * transaction.  The supplied value must not be older than any active read timestamps.  See
-	 * @ref transaction_timestamps., a string; default empty.}
+	 * transaction.  The supplied value must not be older than any active read timestamps\, and
+	 * must not be older than the current stable timestamp.  May be set only once per
+	 * transaction\, and must be set before setting the commit timestamp.  Setting the prepare
+	 * timestamp does not by itself prepare the transaction\, but does oblige the application to
+	 * eventually prepare the transaction before committing it.  See @ref timestamp_prepare., a
+	 * string; default empty.}
 	 * @config{read_timestamp, read using the specified timestamp.  The supplied value must not
 	 * be older than the current oldest timestamp.  This can only be set once for a transaction.
-	 * See @ref transaction_timestamps., a string; default empty.}
+	 * See @ref timestamp_txn_api., a string; default empty.}
 	 * @configend
 	 * @errors
 	 */
@@ -1897,8 +1906,8 @@ struct __wt_session {
 	 * @config{get, specify which timestamp to query: \c commit returns the most recently set
 	 * commit_timestamp.  \c first_commit returns the first set commit_timestamp.  \c prepare
 	 * returns the timestamp used in preparing a transaction.  \c read returns the timestamp at
-	 * which the transaction is reading at.  See @ref transaction_timestamps., a string\, chosen
-	 * from the following options: \c "commit"\, \c "first_commit"\, \c "prepare"\, \c "read";
+	 * which the transaction is reading at.  See @ref timestamp_txn_api., a string\, chosen from
+	 * the following options: \c "commit"\, \c "first_commit"\, \c "prepare"\, \c "read";
 	 * default \c read.}
 	 * @configend
 	 * @errors
@@ -2162,11 +2171,12 @@ struct __wt_connection {
 	 * processing., a boolean flag; default \c false.}
 	 * @config{&nbsp;&nbsp;&nbsp;&nbsp;
 	 * table_logging, if true\, write transaction related information to the log for all
-	 * operations\, even operations for tables with logging turned off.  This setting introduces
-	 * a log format change that may break older versions of WiredTiger.  These operations are
-	 * informational and skipped in recovery., a boolean flag; default \c false.}
-	 * @config{&nbsp;&nbsp;&nbsp;&nbsp;update_restore_evict, if true\, control all dirty page
-	 * evictions through forcing update restore eviction., a boolean flag; default \c false.}
+	 * operations\, even operations for tables with logging turned off.  This additional logging
+	 * information is intended for debugging and is informational only\, that is\, it is ignored
+	 * during recovery., a boolean flag; default \c false.}
+	 * @config{&nbsp;&nbsp;&nbsp;&nbsp;
+	 * update_restore_evict, if true\, control all dirty page evictions through forcing update
+	 * restore eviction., a boolean flag; default \c false.}
 	 * @config{ ),,}
 	 * @config{error_prefix, prefix string for error messages., a string; default empty.}
 	 * @config{eviction = (, eviction configuration options., a set of related configuration
@@ -2480,8 +2490,8 @@ struct __wt_connection {
 	 * most recent stable checkpoint taken prior to a shutdown and \c stable_timestamp returns
 	 * the most recent \c stable_timestamp set with WT_CONNECTION::set_timestamp.  (The \c
 	 * oldest and \c stable arguments are deprecated short-hand for \c oldest_timestamp and \c
-	 * stable_timestamp\, respectively.) See @ref transaction_timestamps., a string\, chosen
-	 * from the following options: \c "all_durable"\, \c "last_checkpoint"\, \c "oldest"\, \c
+	 * stable_timestamp\, respectively.) See @ref timestamp_global_api., a string\, chosen from
+	 * the following options: \c "all_durable"\, \c "last_checkpoint"\, \c "oldest"\, \c
 	 * "oldest_reader"\, \c "oldest_timestamp"\, \c "pinned"\, \c "recovery"\, \c "stable"\, \c
 	 * "stable_timestamp"; default \c all_durable.}
 	 * @configend
@@ -2508,21 +2518,21 @@ struct __wt_connection {
 	 * timestamps greater than the specified value until the next durable timestamp moves the
 	 * tracked durable timestamp forwards.  This is only intended for use where the application
 	 * is rolling back locally committed transactions.  The supplied value must not be older
-	 * than the current oldest and stable timestamps.  See @ref transaction_timestamps., a
-	 * string; default empty.}
+	 * than the current oldest and stable timestamps.  See @ref timestamp_global_api., a string;
+	 * default empty.}
 	 * @config{force, set timestamps even if they violate normal ordering requirements.  For
 	 * example allow the \c oldest_timestamp to move backwards., a boolean flag; default \c
 	 * false.}
 	 * @config{oldest_timestamp, future commits and queries will be no earlier than the
 	 * specified timestamp.  Supplied values must be monotonically increasing\, any attempt to
 	 * set the value to older than the current is silently ignored.  The supplied value must not
-	 * be newer than the current stable timestamp.  See @ref transaction_timestamps., a string;
+	 * be newer than the current stable timestamp.  See @ref timestamp_global_api., a string;
 	 * default empty.}
 	 * @config{stable_timestamp, checkpoints will not include commits that are newer than the
 	 * specified timestamp in tables configured with \c log=(enabled=false). Supplied values
 	 * must be monotonically increasing\, any attempt to set the value to older than the current
 	 * is silently ignored.  The supplied value must not be older than the current oldest
-	 * timestamp.  See @ref transaction_timestamps., a string; default empty.}
+	 * timestamp.  See @ref timestamp_global_api., a string; default empty.}
 	 * @configend
 	 * @errors
 	 */
@@ -2530,19 +2540,14 @@ struct __wt_connection {
 	    WT_CONNECTION *connection, const char *config);
 
 	/*!
-	 * Rollback in-memory non-logged state to an earlier point in time.
-	 *
-	 * This method uses a timestamp to define the rollback point, and requires the application
-	 * use timestamps, the stable_timestamp have been set via a call to
-	 * WT_CONNECTION::set_timestamp, and a checkpoint operating on the last stable timestamp
-	 * to have completed. Any updates to checkpoint durable tables that are more recent than
-	 * the stable timestamp are removed.
+	 * Rollback tables to an earlier point in time, discarding all updates to checkpoint durable
+	 * tables that have commit times more recent than the current global stable timestamp.
 	 *
-	 * This method requires that there are no open cursors or active operations for the duration
-	 * of the call.
+	 * No updates made to logged tables or updates made without an associated commit timestamp
+	 * will be discarded. See @ref timestamp_misc.
 	 *
-	 * Any updates made to logged tables will not be rolled back. Any updates made without an
-	 * associated timestamp will not be rolled back. See @ref transaction_timestamps.
+	 * Applications should close or reset all open cursors before the call, and no other API
+	 * calls should be made for the duration of the call.
 	 *
 	 * @snippet ex_all.c rollback to stable
 	 *
@@ -2883,11 +2888,12 @@ struct __wt_connection {
  * @config{&nbsp;&nbsp;&nbsp;&nbsp;slow_checkpoint, if true\, slow down checkpoint
  * creation by slowing down internal page processing., a boolean flag; default \c false.}
  * @config{&nbsp;&nbsp;&nbsp;&nbsp;table_logging, if true\, write transaction related information to
- * the log for all operations\, even operations for tables with logging turned off.  This setting
- * introduces a log format change that may break older versions of WiredTiger.  These operations are
- * informational and skipped in recovery., a boolean flag; default \c false.}
- * @config{&nbsp;&nbsp;&nbsp;&nbsp;update_restore_evict, if true\, control all dirty page evictions
- * through forcing update restore eviction., a boolean flag; default \c false.}
+ * the log for all operations\, even operations for tables with logging turned off.  This additional
+ * logging information is intended for debugging and is informational only\, that is\, it is ignored
+ * during recovery., a boolean flag; default \c false.}
+ * @config{&nbsp;&nbsp;&nbsp;&nbsp;
+ * update_restore_evict, if true\, control all dirty page evictions through forcing update restore
+ * eviction., a boolean flag; default \c false.}
  * @config{ ),,}
  * @config{direct_io, Use \c O_DIRECT on POSIX systems\, and \c FILE_FLAG_NO_BUFFERING on Windows to
  * access files.  Options are given as a list\, such as <code>"direct_io=[data]"</code>. Configuring