[SERVER-21738] Definitively detect no-op updates Created: 02/Dec/15  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Write Ops
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Eric Milkie Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-21726 WiredTiger primaries replicate no-op ... Closed
related to SERVER-36405 Update should be smarter about recogn... Backlog
Assigned Teams:
Query Execution
Participants:

 Description   

From SERVER-21726, it became clear that we need a new way to detect no-ops from update modifiers that works for all storage engines and regardless of whether replication is active.



 Comments   
Comment by Eric Milkie [ 04/Jan/19 ]

I would argue it is still relevant (the code is still fragile), but now that we have removed mmapv1, in-place update support is irrelevant, so it makes completing this ticket much easier.

SERVER-36405 is to improve the update code so that more no-op scenarios are detected at all, and is a lot more work.  This ticket here was my proposal to simply move the logic that avoids logging no-op updates that were already detected by the current code logic.

Comment by Asya Kamsky [ 04/Jan/19 ]

Is this still relevant and if so is it different from SERVER-36405?

Comment by Eric Milkie [ 10/May/16 ]

Today, we detect no-op updates by hacking the onUpdate op listener, which is only active for replication. There didn't seem to be a common code path place to determine no-op-ness in the current update code; the path branches based on whether the storage engine supports in-place update.

Generated at Thu Feb 08 03:58:16 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.