-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
gc: end to end integration test #87516
Conversation
9a98d74
to
c182ccf
Compare
Feel free to request direct review when ready, I think you're probably still fiddling with this given our recent slack convo ;-) |
c182ccf
to
d01f9ee
Compare
Those were just minor tweaking of TestCluster settings and it looks like it passed all the stress and race. Should be ok to review. |
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.
Reviewed 3 of 3 files at r1, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aliher1911)
pkg/kv/kvserver/gc/gc_int_test.go
line 73 at r1 (raw file):
statusServer := tc.Server(0).StatusServer().(serverpb.StatusServer) execOrFatal := func(stmt string, args ...interface{}) {
Take t *testing.T
here, and call t.Helper()
, that way you can tell which caller fataled.
pkg/kv/kvserver/gc/gc_int_test.go
line 78 at r1 (raw file):
} getTableRangeIDs := func(db *gosql.DB) ids {
Please pass *testing.T
in all the methods and call t.Helper
.
pkg/kv/kvserver/gc/gc_int_test.go
line 91 at r1 (raw file):
} readSomeKeys := func(db *gosql.DB) []int64 {
ditto
pkg/kv/kvserver/gc/gc_int_test.go
line 103 at r1 (raw file):
} getRangeInfo := func(rangeID int64, db *gosql.DB) (startKey, endKey []byte) {
ditto
pkg/kv/kvserver/gc/gc_int_test.go
line 111 at r1 (raw file):
} deleteRangeDataWithRangeTombstone := func(rangeIDs []int64, kvDb *kv.DB) {
ditto
pkg/kv/kvserver/gc/gc_int_test.go
line 119 at r1 (raw file):
} getRangeStats := func(rangeID int64) enginepb.MVCCStats {
ditto
pkg/kv/kvserver/gc/gc_int_test.go
line 129 at r1 (raw file):
} findNonEmptyRanges := func(rangeIDs ids) (nonEmptyRangeIDs ids) {
ditto
pkg/kv/kvserver/gc/gc_int_test.go
line 132 at r1 (raw file):
for _, id := range rangeIDs { stats := getRangeStats(id) t.Logf("range %d stats: %s", id, &stats)
Need to check somewhere that ContainsEstimates
is false.
pkg/kv/kvserver/gc/gc_int_test.go
line 165 at r1 (raw file):
require.Empty(t, readSomeKeys(sqlDb), "table still contains data after range deletion") execOrFatal(`alter table kv split at values ($1)`, math.MaxInt64/2)
Why? And why now?
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aliher1911 and @tbg)
pkg/kv/kvserver/gc/gc_int_test.go
line 132 at r1 (raw file):
Previously, tbg (Tobias Grieger) wrote…
Need to check somewhere that
ContainsEstimates
is false.
Can we have ContainsEstimates
true here? I thought they are produced by imports and the such operations. If there are estimates, we won't be able to assert the test result and we can't reasonably recover. We can fail the whole test though.
pkg/kv/kvserver/gc/gc_int_test.go
line 165 at r1 (raw file):
Previously, tbg (Tobias Grieger) wrote…
Why? And why now?
Checking that range that was split by range split is still deleted correctly.
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aliher1911)
pkg/kv/kvserver/gc/gc_int_test.go
line 132 at r1 (raw file):
Previously, aliher1911 (Oleg) wrote…
Can we have
ContainsEstimates
true here? I thought they are produced by imports and the such operations. If there are estimates, we won't be able to assert the test result and we can't reasonably recover. We can fail the whole test though.
Right, just assert it's false basically.
pkg/kv/kvserver/gc/gc_int_test.go
line 165 at r1 (raw file):
Previously, aliher1911 (Oleg) wrote…
Checking that range that was split by range split is still deleted correctly.
Maybe add a comment, seems kind of unclear why, but it doesn't hurt either. Is there any interaction with splits that is interesting here? You push them through the queue separately, so it looks the same to me, just doing it twice rather than once.
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @aliher1911)
Currently tests are covering various components, but there's no end to end flow test that would verify that GC will issue GC requests that would successfully remove all relevant data. This commit adds a TestCluster based test to verify GC behaviour. Release justification: test only change Release note: None
d01f9ee
to
968c845
Compare
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.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @tbg)
pkg/kv/kvserver/gc/gc_int_test.go
line 78 at r1 (raw file):
Previously, tbg (Tobias Grieger) wrote…
Please pass
*testing.T
in all the methods and callt.Helper
.
What is the benefit of passing t to every helper lambda here, to avoid accessing variables from outer scope? Currently it's a mixed bag, some functions receive connection and some use it from test function itself, I'll fix that as well then.
pkg/kv/kvserver/gc/gc_int_test.go
line 165 at r1 (raw file):
Previously, tbg (Tobias Grieger) wrote…
Maybe add a comment, seems kind of unclear why, but it doesn't hurt either. Is there any interaction with splits that is interesting here? You push them through the queue separately, so it looks the same to me, just doing it twice rather than once.
You are right, I now think it doesn't belong here. Updating stats should be tested on split/merge separately.
bors r=tbg |
Build succeeded: |
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.
Reviewable status: complete! 0 of 0 LGTMs obtained
pkg/kv/kvserver/gc/gc_int_test.go
line 78 at r1 (raw file):
Previously, aliher1911 (Oleg) wrote…
What is the benefit of passing t to every helper lambda here, to avoid accessing variables from outer scope? Currently it's a mixed bag, some functions receive connection and some use it from test function itself, I'll fix that as well then.
https://play.golang.com/p/hWebTlxd9Nk
It makes sure that the errors that get created are made to originate from the line of the caller, not the line of the helper. Note how the calls to badHelper
can't be traced back to where they were called from.
This is less of an issue with using require
because that always logs a stack trace anyway, but it's better to pass t
explicitly just as muscle memory, since not everything uses require
.
I don't need to pass t to make helper work as I think it .Helper() only ensures stack frames where helper was invoked are ignored: So we can achieve the same with just using t from main test function. I'm more interested in, if I pass t, then I'd rather pass everything and make this a proper function. I don't see why t has any special meaning here. Either go full on with inheriting everything or pass everything every time. Imho for function literals there's little benefit of passing all shared variables as you will always pass the same values within context of your test anyways. |
Yeah, fair point. |
This only seems to test the range tombstone full-range fast path? Shouldn't we also, at minimum, test that point keys and range keys are GCed correctly, both for updates and deletes? |
Currently tests are covering various components, but there's no end to end flow test that would verify that GC will issue GC requests that would successfully remove all relevant data.
This commit adds a TestCluster based test to verify GC behaviour.
Release justification: test only change
Release note: None
Fixes #84988