[SERVER-38906] Multi-document transactions should not perform timestamped read ahead of all-committed Created: 09/Jan/19 Updated: 29/Oct/23 Resolved: 22/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 4.1.9 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Tess Avitabile (Inactive) | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | prepare_basic | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||
| Sprint: | Repl 2019-01-28, Repl 2019-02-11, Repl 2019-02-25, Repl 2019-03-11 | ||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 10 | ||||||||||||||||||||||||||||||||||||
| Description |
|
Multi-document transactions with read concern level local or majority perform a timestamped read at the lastApplied. Since the lastApplied is ahead of the all-committed, after the work to allow WT read at a timestamp without a snapshot, this could cause these transactions to read uncommitted storage transactions. It is essential that multi-document transactions with read concern level local read at lastApplied, so that w:1 writes are visible to these transactions. As a solution, multi-document transactions reading ahead of all-committed will not perform a timestamped read. |
| Comments |
| Comment by Githook User [ 22/Feb/19 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'username': 'ajdavis', 'email': 'jesse@mongodb.com'}Message: |
| Comment by Githook User [ 22/Feb/19 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: |
| Comment by A. Jesse Jiryu Davis [ 20/Feb/19 ] |
|
Still to do: test that proves local transactions that only read do a noop write. |
| Comment by Githook User [ 20/Feb/19 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'username': 'ajdavis', 'email': 'jesse@mongodb.com'}Message: |
| Comment by Githook User [ 20/Feb/19 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'username': 'ajdavis', 'email': 'jesse@mongodb.com'}Message: |
| Comment by Tess Avitabile (Inactive) [ 08/Feb/19 ] |
|
jesse, for performing a noop write, you could generalize the utility here. |
| Comment by Daniel Gottlieb (Inactive) [ 06/Feb/19 ] |
|
There's been some miscommunication (that starts with me). There is a project that can change what readers in front of holes can see, but the outcome may be something other than "possibly read uncommitted data". |
| Comment by Githook User [ 05/Feb/19 ] |
|
Author: {'name': 'A. Jesse Jiryu Davis', 'email': 'jesse@mongodb.com', 'username': 'ajdavis'}Message: |
| Comment by Tess Avitabile (Inactive) [ 04/Feb/19 ] |
|
However, I hear your point that transactions that only read should behave like updates where nupdated is 0. |
| Comment by Andy Schwerin [ 04/Feb/19 ] |
|
Transactions that only read should behave like updates where nupdated is 0. If I understand correctly, |
| Comment by A. Jesse Jiryu Davis [ 04/Feb/19 ] |
|
schwerin the solution to this ticket will cause a subtle behavior change that Tess explained to me, I want to check with you that the change is ok. Consider a multi-statement transaction that only reads, configured with readConcern local and writeConcern majority. (The readConcern is passed with the first command of the transaction, the writeConcern is passed with the commitTransaction command.) Today, such a transaction reads from the lastApplied timestamp, and then commitTransaction waits for that timestamp to become majority committed. So, I think today's read-only transaction behavior is "speculative majority". We're changing the code to read with no timestamp. WiredTiger will somehow pick a snapshot for us. When we receive commitTransaction with writeConcern majority, we won't wait for any timestamp to be majority-committed. (We can't get the lastApplied at the end of the transaction and wait for it to be majority-committed, due to So, this is a subtle change. Read-only transactions with readConcern local and writeConcern majority will become "truly local", and they'll happily commit without knowing whether they have read data that wasn't majority-committed. This may go against your goal to make “speculative majority” the default readConcern for operations that can write. Is this an okay change or shall we reconsider how to solve this ticket? |
| Comment by Judah Schvimer [ 31/Jan/19 ] |
|
This ticket should unblacklist tests blacklisted in this commit ( |