Keith wrote:

The question arose because the current txn.commit code can fail but still
commit, which seems wrong: the semantics of txn.commit are it either
returns 0 or the txn was rolled back, correct? If cursor.close fails, but
we still call txn.commit, I don't see how we can return an error and still
commit the txn.

IIRC, in Berkeley DB there was the problem of partial changes, that is, if
we made some changes for a logical API call, but then encountered a
WT_DEADLOCK after making those changes, before we finished the API call,
then we had to roll-back the partial change or we'd have corruption. If
that isn't happening here, we're saying we'll never have an API call in a
transaction that can be partially completed and need to be rolled-back when
we return WT_DEADLOCK. (Or, that we'll roll it back internally before we
return WT_DEADLOCK.)

Can WT make that statement, that you will always be able to continue &
commit after a cursor operation fails with WT_DEADLOCK?

That's why I'm more comfortable with "if you see any errors, it's gonna
abort, we don't care what you do" as a semantic.