Skip to content
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

raft: remove atomicTimestamp for fortificationtracker #138705

Merged
merged 1 commit into from
Jan 15, 2025

Conversation

iskettaneh
Copy link
Contributor

@iskettaneh iskettaneh commented Jan 9, 2025

This commit removes the struct atomicTimestamp and replaces
it with hlc.Timestamp directly without locks. This is now
possible as we only update LeadSupportUntil every tick, and
it won't change on every status call.

References: #137264

Release note: None

@iskettaneh iskettaneh requested a review from arulajmani January 9, 2025 00:53
@iskettaneh iskettaneh requested a review from a team as a code owner January 9, 2025 00:53
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@iskettaneh iskettaneh changed the title raft: add and compute lastComputedLeadSupportUntil raft: remove atomicTimestamp for fortificationtracker Jan 9, 2025
@iskettaneh iskettaneh force-pushed the RaftLSU3 branch 4 times, most recently from f9e3b74 to 29e9c09 Compare January 14, 2025 14:56
Copy link
Collaborator

@arulajmani arulajmani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 8 of 8 files at r2, all commit messages.
Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @iskettaneh)


-- commits line 7 at r2:
nit: consider adding some words about Status calls only only holding a read lock.


pkg/raft/tracker/fortificationtracker.go line 92 at r2 (raw file):

	// computedLeadSupportUntil is the last computed LeadSupportUntil. We
	// update this value on:
	// [1] Every tick.

nit: "1." to match other places in the code where we use numbered lists.


pkg/raft/tracker/fortificationtracker.go line 94 at r2 (raw file):

	// [1] Every tick.
	// [2] Every time a new fortification is recorded.
	// [3] On config changes. Callers of LeadSupportUntil will get this cached

nit:
"Callers of LeadSupport..." should be its own paragraph.


pkg/raft/tracker/fortificationtracker.go line 190 at r2 (raw file):

// ComputeLeadSupportUntil updates the field
// computedLeadSupportUntil by computing the LeadSupportExpiration.
func (ft *FortificationTracker) ComputeLeadSupportUntil(state pb.StateType) hlc.Timestamp {

Can we get rid of the return parameter here? IIUC, no one is using it.


pkg/raft/tracker/fortificationtracker.go line 199 at r2 (raw file):

		return ft.computedLeadSupportUntil // fast-path for no fortification
	}

Should we have an early return for ft.steppingDown? That way, we don't need to do the computation.


pkg/raft/tracker/fortificationtracker.go line 359 at r2 (raw file):

	//
	// NB: Only run by the leader.
	fmt.Printf("!!! IBRAHIM !!! ConfigChangeSafe. ft.leaderMaxSupported: %+v, ft.computedLeadSupportUntil: %+v\n", ft.leaderMaxSupported, ft.computedLeadSupportUntil)

nit": detritus.


pkg/raft/raft.go line 880 at r2 (raw file):

		return
	}
	fmt.Printf("!!! IBRAHIM !!! sending MsgDeFortifyLeader to %v\n", to)

nit: detritus? here, and a bunch of Pritnfs in this file.

Copy link
Contributor Author

@iskettaneh iskettaneh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @arulajmani)


pkg/raft/raft.go line 880 at r2 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

nit: detritus? here, and a bunch of Pritnfs in this file.

Oh sorry about that. I did some debugging yesterday night to make sure that things are working as expected, and I must have forgot to remove the debug logs.


pkg/raft/tracker/fortificationtracker.go line 190 at r2 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

Can we get rid of the return parameter here? IIUC, no one is using it.

Done.


pkg/raft/tracker/fortificationtracker.go line 199 at r2 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

Should we have an early return for ft.steppingDown? That way, we don't need to do the computation.

Done.

@iskettaneh iskettaneh requested a review from arulajmani January 14, 2025 18:06
Copy link
Collaborator

@arulajmani arulajmani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewed 2 of 2 files at r3, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @iskettaneh)


pkg/raft/tracker/fortificationtracker.go line 203 at r3 (raw file):

	if ft.steppingDown {
		return // fast-path for stepping down

nit: this could use a better comment. Consider saying something like "We're in the process of stepping down, so we don't want to advance the LeadSupportUntil; early return"

This commit removes the struct atomicTimestamp and replaces
it with hlc.Timestamp directly without locks. This is now
possible as we only update LeadSupportUntil every tick, and
it won't change on every status call, which are called while
we hold the read lock.

References: cockroachdb#137264

Release note: None
@iskettaneh
Copy link
Contributor Author

TFTR!

bors r+

craig bot pushed a commit that referenced this pull request Jan 15, 2025
138705: raft: remove atomicTimestamp for fortificationtracker r=iskettaneh a=iskettaneh

This commit removes the struct atomicTimestamp and replaces
it with hlc.Timestamp directly without locks. This is now
possible as we only update LeadSupportUntil every tick, and
it won't change on every status call.

References: #137264

Release note: None

138976: backup: remove support for kv.bulkio.write_metadata_sst.enabled r=jeffswenson a=jeffswenson

kv.bulkio.write_metadata_sst.enabled causes backup to write out a 'metadata.sst' file. This file was never used in production, but some of the code is used by the new thin manifest format.

The code that is still used was moved into new files to fix the build as a refactoring trick to ensure all unused code was deleted.

Epic: none
Release Note: none

Co-authored-by: Ibrahim Kettaneh <[email protected]>
Co-authored-by: Jeff Swenson <[email protected]>
@craig
Copy link
Contributor

craig bot commented Jan 15, 2025

This PR was included in a batch that was canceled, it will be automatically retried

@craig craig bot merged commit f1f678e into cockroachdb:master Jan 15, 2025
22 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants