-
Notifications
You must be signed in to change notification settings - Fork 4.1k
sql: investigate why catalog Lease tests do not work with a shared process virtual cluster #112957
Copy link
Copy link
Closed
Labels
A-multitenancyRelated to multi-tenancyRelated to multi-tenancyC-investigationFurther steps needed to qualify. C-label will change.Further steps needed to qualify. C-label will change.T-sql-foundationsSQL Foundations Team (formerly SQL Schema + SQL Sessions)SQL Foundations Team (formerly SQL Schema + SQL Sessions)target-release-26.2.0v26.2.0-prerelease
Description
Describe the problem
When running some lease tests (all marked with this issue) with a shared process virtual cluster:
=== RUN TestLeaseManagerReacquire
test_log_scope.go:170: test logs captured to: /var/folders/sh/9k10t77143q0f1ffxxv99lbh0000gq/T/logTestLeaseManagerReacquire3104296236
test_log_scope.go:81: use -show-logs to present logs inline
lease_test.go:415: expected different leases, but found 104("foo") ver=1:1698146574.830708472,0, refcount=2
panic.go:522: -- test log scope end --
test logs left over in: /var/folders/sh/9k10t77143q0f1ffxxv99lbh0000gq/T/logTestLeaseManagerReacquire3104296236
--- FAIL: TestLeaseManagerReacquire (3.33s)
How to reproduce
Set the following in TestServerArgs to force a shared process tenant and cause the failure to happen.
DefaultTestTenant: base.SharedTestTenantAlwaysEnabled,
Expected behavior
The test should pass when running with a shared process virtual cluster, unless after investigation the test is expected not to work with one.
Ref: #112857
Epic CRDB-48944
Jira issue: CRDB-32694
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
A-multitenancyRelated to multi-tenancyRelated to multi-tenancyC-investigationFurther steps needed to qualify. C-label will change.Further steps needed to qualify. C-label will change.T-sql-foundationsSQL Foundations Team (formerly SQL Schema + SQL Sessions)SQL Foundations Team (formerly SQL Schema + SQL Sessions)target-release-26.2.0v26.2.0-prerelease