csuite-timestamp-abort-test failed on ! Ubuntu 18.04 ASAN

Host: ec2-52-201-164-48.compute-1.amazonaws.com
Project: WiredTiger (develop)
Commit: diff: WT-6403 restore format non-timestamp transactional testing (#6509)

• Restore non-timestamp transaction testing in format. Format now runs in one of two modes,
  either timestamp (TS) transactions or non-timestamp (non-TS) transactions, governed by the
  transaction.timestamp configuration string, turning that configuration string off configures
  non-TS runs.

TS transactions only use snapshot isolation, non-TS transactions do all updates in snapshot
isolation, but do reads in both snapshot and lower-level isolations.

WT_CURSOR.remove inside an implicit transaction could fail with "key not set" if the underlying
btree routine returned rollback. The current behavior is we must fail if the cursor position
is initially set and we lose that position somehow, change the API's implicit transaction macros
to return WT_ROLLBACK in the case where retry isn't an option.
Remove the TXN_API_END_RETRY macro, it has only one caller, rename TXN_API_END.
Remove a test in TXN_API_END() of ret == 0, it cannot be 0 at that point.

Update method documentation to note that all object updates and calls to WT_SESSION.query_timestamp
must be done at snapshot isolation.

Remove documentation note that all uncommitted transactions must fit into memory, that is no
longer true (for example, prepared transactions).

Update format to not configure the isolation level where the default level (snapshot) is correct.

Remove disabled lower-level isolation test from evergreen.yml, TS runs are never going to
support isolation levels other than snapshot.

Remove format's transaction.isolation configuration string, TS runs will never support isolation
levels other than snapshot, and non-TS runs will only do reads at lower-levels than snapshot.

Rename format's "transaction.frequency" configuration string to "transation.implicit", as TS
runs do not support implicit transactions. The new configuration string sets the percentage of
non-TS operations that are done inside implicit transactions, rather than explicit transactions.

Remove the assert.commit_timestamp string, it's no longer supported by the library.

Add an assert.read_timestamp configuration string to support "assert=(read_timestamp=VALUE)",
with the value of always in the case of TS runs, and never in the case of non-TS runs.

Add an assert.write_timestamp configuration string to support the library configuration
"assert=(write_timestamp=on), write_timestamp_usage=VALUE", with the value of always in the
case of TS runs, and never in the case of non-TS runs.

Remove the transaction.rollback_to_stable configuration string and change it to always be called
in both TS and non-TS runs. Change rollback-to-stable to not do additional checks against saved
operations unless in a TS run.

• Don't do rollback-to-stable for in-memory configurations.

• RTS should only be called from the application with timestamps are configured.

• Don't use WT_TRET unless we're accumulating/replacing errors in a path we can't exit immediately.

• WT_VA_ARGS_BUF_FORMAT() can't immediately return out of the macro, it's called from __wt_msg()
  and __wt_ext_msg_printf(), functions that allocate buffers and have to free them on error.

• Errors in __wt_rollback_to_stable() need an error lable so they can close the internal session
  opened in the function.

• If running without timestamps, each insert is a committed row, so use the number of inserts to correct
  the key count, not the number of keys included in explicitly committed transactions.

• Assert that WT_CONNECTION.rollback_to_stable returns success.

When repeating reads after rollback-to-stable, don't bother checking if the repeatable read
timestamp is less than the global timestamp, the underlying read function handles that as an
EINVAL return from setting the read timestsamp.

When repeating reads (both in the normal case and after rollback-to-stable), handle WT_ROLLBACK
returns by ignoring the error and repeating the operation. Eviction may choose to rollback our
transaction, but it should eventually complete.

When repeating reads (both in the normal case and after rollback-to-stable), don't treat cache-full
as an expected error, these are read-only transactions which should not trigger cache-full checks.

• Copying the database state before calling rollback-to-stable is tricky, operations may be running
  inside of WiredTiger (for example, checkpoints), and so the list of files can change underfoot.
  Remove that code until we have a debugging case that needs it.

• Rework transaction option testing, we weren't respecting cases where options were required for a
  run.

• Simplify transaction configuration a little, separate checks for incompatible configurations
  required by the run from the work to pick a compatible set of configurations for the run. | 16 May 21 23:47 UTC
  Evergreen Subscription: ; Evergreen Event:

Task Logs