- 
                Notifications
    
You must be signed in to change notification settings  - Fork 1.4k
 
Guard Resolver Private Mutations Work #12498
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
base: main
Are you sure you want to change the base?
Conversation
          Result of foundationdb-pr-clang-ide on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
  | 
    
          Result of foundationdb-pr-clang-arm on Linux CentOS 7
  | 
    
          Result of foundationdb-pr-clang on Linux RHEL 9
  | 
    
          Result of foundationdb-pr on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-cluster-tests on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-macos on macOS Ventura 13.x
  | 
    
7b6009b    to
    b4292b9      
    Compare
  
    
          Result of foundationdb-pr-clang-ide on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-clang on Linux RHEL 9
  | 
    
          Result of foundationdb-pr on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
  | 
    
          Result of foundationdb-pr-clang-arm on Linux CentOS 7
  | 
    
          Result of foundationdb-pr-clang-ide on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-clang on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-cluster-tests on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-clang-arm on Linux CentOS 7
  | 
    
          Result of foundationdb-pr on Linux RHEL 9
  | 
    
This reverts commit 505e0cb.
4ff89fe    to
    53713c2      
    Compare
  
    
          Result of foundationdb-pr-cluster-tests on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-clang-ide on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-clang-ide on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
  | 
    
          Result of foundationdb-pr-clang-arm on Linux CentOS 7
  | 
    
          Result of foundationdb-pr-clang-arm on Linux CentOS 7
  | 
    
          Result of foundationdb-pr-clang on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-cluster-tests on Linux RHEL 9
  | 
    
        
          
                fdbserver/Resolver.actor.cpp
              
                Outdated
          
        
      | // merge mutation tags with sent client tags | ||
| toCommit->saveTags(reply.writtenTags); | ||
| reply.privateMutationCount = toCommit->getMutationCount(); | ||
| reply.privateMutationCount = applyResolverPrivateMutations ? toCommit->getMutationCount() : 0; | 
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.
Same question: why checking for "applyResolverPrivateMutations" here?
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.
why checking for "applyResolverPrivateMutations" here?
privateMutationCount should only be non-zero when we actually applied resolver private mutations for this batch. Gating with applyResolverPrivateMutations keeps this consistent with the nearby haveLogsChanged() checks. i.e. "no state txns ⇒ count must be 0.”
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.
privateMutationCount should only be non-zero when we actually applied resolver private mutations for this batch.
Probably we can add an assert and run a Joshua job to validate this (I don't fully understand this code so I can't say for sure this is true).
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.
private mutations are only generated when we call applyMetadataMutations() above, which is conditioned on req.txnStateTransactions.
shouldApplyResolverPrivateMutations = SERVER_KNOBS->PROXY_USE_RESOLVER_PRIVATE_MUTATIONS && !req.txnStateTransactions.empty(); So the change is correct. But honestly I don't know if this is an optimization, toCommit->getMutationCount() is very fast anyway,
uint32_t getMutationCount() const { return subsequence - 1; }
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.
honestly I don't know if this is an optimization
its not an optimization; we cannot deref toCommit here unless applyResolverPrivateMutations is true
          Result of foundationdb-pr-macos on macOS Ventura 13.x
  | 
    
          Result of foundationdb-pr-clang-ide on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
  | 
    
          Result of foundationdb-pr-clang-arm on Linux CentOS 7
  | 
    
          Result of foundationdb-pr on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-clang on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-cluster-tests on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-macos on macOS Ventura 13.x
  | 
    
          Result of foundationdb-pr-clang-ide on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-macos-m1 on macOS Ventura 13.x
  | 
    
          Result of foundationdb-pr-cluster-tests on Linux RHEL 9
  | 
    
          Result of foundationdb-pr-clang-arm on Linux CentOS 7
  | 
    
          Result of foundationdb-pr-clang on Linux RHEL 9
  | 
    
          Result of foundationdb-pr on Linux RHEL 9
  | 
    
On the resolver, only construct ResolverData, read databaseLockedKey, and invoke applyMetadataMutations when the batch actually contains state transactions. Keep the LogPushData object alive in each batch so the commit proxy still receives the metadata replay.
100K USE_RESOLVER_PRIVATE_MUTATIONS enabled
20251023-171528-dlambrig-4eb9e1acb2dc286420251103-205727-dlambrig-5ffe617bc6aa1d72(11-3-25)100K USE_RESOLVER_PRIVATE_MUTATIONS disabled
20251023-171420-dlambrig-735d7123309317ab20251103-160029-dlambrig-7dd92c5eee5f38c2(11-3-25)Code-Reviewer Section
The general pull request guidelines can be found here.
Please check each of the following things and check all boxes before accepting a PR.
For Release-Branches
If this PR is made against a release-branch, please also check the following:
release-branchormainif this is the youngest branch)