To support SERVER-32876, in WT-3926 we allowed WT_SESSION::timestamp_transaction to set the read_timestamp on a running transaction. This was done because WT_SESSION::begin_transaction is relatively heavyweight, and waits if the cache is overfull, whereas setting a read timestamp may hold an application lock.

However, this pattern:

session->begin_transaction(...)
acquire lock
get a timestamp
session->timestamp_transaction("read_timestamp=X")

is currently unsafe. That is because a concurrent transaction could commit while this one is waiting for the lock, with a transaction ID that is not visible to the snapshot allocated when the transaction starts, even though it has a timestamp less than X.

One solution is to update the snapshot during the timestamp_transaction call, but that means it will become a common case to get a snapshot, throw it away, then get a new one here. Since getting a snapshot can be somewhat costly, we would prefer not to slow down the common case.