-
Notifications
You must be signed in to change notification settings - Fork 853
Bug-fix-3.8/make iterator usage safer after intermediate commits #14729
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug-fix-3.8/make iterator usage safer after intermediate commits #14729
Conversation
* Lower priority of AQL lanes * Added CHANGELOG entry * Improved comments Co-authored-by: Vadim <vadim@arangodb.com>
Co-authored-by: mpoeter <manuel@arangodb.com>
…afe-iterators-after-intermediate-commits2
…ix-3.8/safe-iterators-after-intermediate-commits2
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All good except some changes in EngineInfoContainerDBServerBased.cpp that should all be reverted in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Go tests seem to be unreliable atm. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Scope & Purpose
Backport of #14543 and #14346 (which builds upon the former).
Enterprise companion PR: https://github.com/arangodb/enterprise/pull/752
Fix internal iterator states after intermediate commits in write transactions. Iterators could point to invalid data after an intermediate commit, producing undefined behavior.
Fix read-own-write behavior in different scenarios:
To achieve the correct read-own-write behavior in streaming transactions, we sometimes have to copy the internal WriteBatch from the underlying RocksDB transaction. In particular, the copy is created whenever an AQL query with
modification operations (INSERT/REMOVE/UPDATE/UPSERT/REPLACE) is executed in the streaming transaction. If there have not been any other modifications so far (queries/document operations), then the WriteBatch is empty and creating the copy is essentially a no-op. However, if the transaction already contains a lot of modifications, creating the WriteBatch copy might incur some overhead that can now lead to decreased performance.
Testing & Verification