Fix putIntoUnackQueueRing function logic for Intercontect interfaces - #1931
Open
ZTE-EBASE wants to merge 1 commit into
Open
Fix putIntoUnackQueueRing function logic for Intercontect interfaces#1931ZTE-EBASE wants to merge 1 commit into
ZTE-EBASE wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #ISSUE_Number
What does this PR do?
Fix putIntoUnackQueueRing function logic for Intercontect interfaces
what
There are several logic issues in the putIntoUnackQueueRing function.
Defect 1: Redundant idx calculation (Severity: Low-Medium)
Defect 2: Misuse of TIMER_SPAN_LOSS (Severity: Medium)
Defect 3: Redundant conditional judgment (Severity: Very Low)
why
For Defect 1 (Redundant idx calculation):
Performance waste: Each call executes one extra integer division and modulo operation (~5-10ns per call)
Poor maintainability: If someone modifies one formula but forgets the other, it introduces hard-to-debug bugs
Code confusion: Readers wonder "why calculate twice?"
Misleading logs: Line 7054's log shows the first calculation, but line 7058's result is actually used
For Defect 2 (TIMER_SPAN_LOSS misuse):
Time alignment bias: Expected 5ms boundary alignment, actual 2.5ms alignment
Imprecise retransmission timing: May cause packets to trigger retransmission too early or too late
Degraded flow control performance: Affects accuracy of timeout-based mechanisms
Subtle bug: Not immediately obvious during testing but impacts long-term stability
For Defect 3 (Redundant conditional):
Reduced readability: Unnecessary complexity makes code harder to understand
Minor performance overhead: Extra conditional check serves no purpose
Violates "don't repeat yourself" principle: The condition is checked twice unnecessarily
Overall justification:
These are not just cosmetic issues—they affect correctness (Defect 2) and code quality (all three)
Low risk fix with high confidence: changes are localized and don't alter external behavior
Follows best practices: clean code, eliminate redundancy, use correct constants
How
Perform logical fixes on the premise that existing code functionality remains intact.
Type of Change
Breaking Changes
Test Plan
make installcheckmake -C src/test installcheck-cbdb-parallelImpact
Performance:
User-facing changes:
Dependencies:
Checklist
Additional Context
CI Skip Instructions