storage/concurrency: test and bugfix for clearing the locks when the#45080
storage/concurrency: test and bugfix for clearing the locks when the#45080craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
|
This change is |
nvb
left a comment
There was a problem hiding this comment.
Reviewed 5 of 5 files at r1.
Reviewable status:complete! 1 of 0 LGTMs obtained (waiting on @sumeerbhola)
pkg/storage/concurrency/lock_table.go, line 1497 at r1 (raw file):
tree := &t.locks[i] tree.mu.Lock() var locksToClear []*lockState
Heh, I noticed this over in 3f987df as well.
pkg/storage/concurrency/testdata/lock_table/size_limit_exceeded, line 52 at r1 (raw file):
local: num=0 acquire r=req1 k=c durability=r
Add a comment that we don't expect this to add a lock to the table and that we should remove this step entirely when we eventually immediately add replicated locks to the lock table.
pkg/storage/concurrency/testdata/lock_table/size_limit_exceeded, line 87 at r1 (raw file):
---- start-waiting: true
Could you add a print right here?
pkg/storage/concurrency/testdata/lock_table/size_limit_exceeded, line 190 at r1 (raw file):
start-waiting: false acquire r=req8 k=e durability=u
Add a comment that this is whether the lock table hits its size limit and evicts everything except the discovered lock without a reservation.
size limit of the lockTable is exceeded Release note: None
sumeerbhola
left a comment
There was a problem hiding this comment.
Reviewable status:
pkg/storage/concurrency/testdata/lock_table/size_limit_exceeded, line 52 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Add a comment that we don't expect this to add a lock to the table and that we should remove this step entirely when we eventually immediately add replicated locks to the lock table.
Added a slightly different comment. We won't need the unreplicated lock acquisition.
pkg/storage/concurrency/testdata/lock_table/size_limit_exceeded, line 87 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Could you add a
Done
pkg/storage/concurrency/testdata/lock_table/size_limit_exceeded, line 190 at r1 (raw file):
Previously, nvanbenschoten (Nathan VanBenschoten) wrote…
Add a comment that this is whether the lock table hits its size limit and evicts everything except the discovered lock without a reservation.
Done
nvb
left a comment
There was a problem hiding this comment.
Reviewed 1 of 1 files at r2.
Reviewable status:
|
bors r+ |
Build failed |
|
bors r+ |
45039: colexec: exhaust input in sorter benchmarks r=yuzefovich a=asubiotto Some benchmarks were only calling `Next` the expected number of times and failing if a zero batch was encountered. However, operators perform cleanup when a zero batch is returned, so this cleanup step was being elided. It's also more in line with other benchmarks to exhaust the operator before finishing a benchmark. Release note: None (testing code cleanup) 45080: storage/concurrency: test and bugfix for clearing the locks when the r=sumeerbhola a=sumeerbhola size limit of the lockTable is exceeded Release note: None Co-authored-by: Alfonso Subiotto Marques <alfonso@cockroachlabs.com> Co-authored-by: sumeerbhola <sumeer@cockroachlabs.com>
Build succeeded |
size limit of the lockTable is exceeded
Release note: None