jobs,*: read job payload and progress from the job_info table#98608
jobs,*: read job payload and progress from the job_info table#98608craig[bot] merged 1 commit intocockroachdb:masterfrom
Conversation
f904791 to
017c4ca
Compare
017c4ca to
741873f
Compare
miretskiy
left a comment
There was a problem hiding this comment.
I really only have nits.
| if e, ok := fooLogical.(cdctest.EnterpriseTestFeed); ok { | ||
| var bytes []byte | ||
| sqlDB.QueryRow(t, `SELECT payload FROM system.jobs WHERE id=$1`, e.JobID()).Scan(&bytes) | ||
| sqlDB.QueryRow(t, `SELECT payload FROM "".crdb_internal.system_jobs WHERE id = $1`, |
There was a problem hiding this comment.
curious: why do we need "" ?
There was a problem hiding this comment.
Added a comment to jobs_verification.go and changed most test places to use that query instead.
| if err != nil { | ||
| return nil, nil, errors.Wrapf(err, "failed to get payload for job %d", j.ID()) | ||
| } | ||
| if !exists { |
There was a problem hiding this comment.
do we intend on making progress optional at some point?
There was a problem hiding this comment.
maybe. On job creation we expect the job record to have a valid, non-null progress and payload so unless the user manually deletes the progress for a job from system.job_info we will always have an entry. That said SHOW JOBS goes out of its way to handle the absence of a progress row for a job. So I dunno we should decide if having progress is mandatory or not and then apply that through the system.
741873f to
73e06c7
Compare
3cde93b to
e8c1a09
Compare
This change touches all the parts of the code that were relying on the `system.jobs` table to read the payload and/or progress corresponding to a job. If the cluster version has advanced past V23_1JobInfoTableIsBackfilled, every job in the system.jobs table has a payload and progress entry written to the `job_info` table. This change migrates callers to use this new table when reading the payload and progress of a job. The most important changes are in the logic that drives `crdb_internal.system_jobs`, which in turn drives `crdb_internal.jobs` and `SHOW JOBS`. Additionally, there are changes in how the registry resolves the progress and payload when loading or resuming a job. Several tests that read the payload and progress from `system.jobs` now rely on `crdb_internal.system_jobs` to fetch this information from either the jobs table or job_info table depending on the cluster version. Fixes: cockroachdb#97762 Release note: None
9bf6a60 to
90a7b66
Compare
|
|
|
bors r+ |
|
Build failed (retrying...): |
|
Build failed (retrying...): |
|
Build failed: |
|
bors retry |
|
Build succeeded: |
In cockroachdb#98608 some changes were made to the c2c roachtests that caused them to break. This change fixes the tests by querying the correct virutal table. Fixes: cockroachdb#98973 Fixes: cockroachdb#98969 Fixes: cockroachdb#98962 Informs: cockroachdb#98669 Release note: None
In cockroachdb#98608 some changes were made to the c2c roachtests that caused them to break. This change fixes the tests by querying the correct virutal table. Fixes: cockroachdb#98973 Fixes: cockroachdb#98969 Fixes: cockroachdb#98962 Informs: cockroachdb#98669 Release note: None
98981: roachtest: fix c2c roachtests that read job payload r=adityamaru a=adityamaru In #98608 some changes were made to the c2c roachtests that caused them to break. This change fixes the tests by querying the correct virutal table that interacts with both `system.jobs` and `system.job_info`. Fixes: #98973 Fixes: #98969 Fixes: #98962 Informs: #98669 Release note: None 99124: kvserver: don't write MinVersion in unit test r=erikgrinaker a=pavelkalinnikov The checkpoint creation code already writes this file. Since this is a unit test, we are not in a situation that this file can not exist (e.g. mixed versions situation), thus we don't need to write this file again. Epic: none Release note: none Co-authored-by: adityamaru <adityamaru@gmail.com> Co-authored-by: Pavel Kalinnikov <pavel@cockroachlabs.com>
This change touches all the parts of the code that were
relying on the
system.jobstable to read the payload and/orprogress corresponding to a job. If the cluster version has advanced
past V23_1JobInfoTableIsBackfilled, every job in the system.jobs table
has a payload and progress entry written to the
job_infotable.This change migrates callers to use this new table when reading the
payload and progress of a job.
The most important changes are in the logic that drives
crdb_internal.system_jobs,which in turn drives
crdb_internal.jobsandSHOW JOBS. Additionally,there are changes in how the registry resolves the progress and payload
when loading or resuming a job.
Several tests that read the payload and progress from
system.jobsnowrely on
crdb_internal.system_jobsto fetch this information from eitherthe jobs table or job_info table depending on the cluster version.
Fixes: #97762
Release note: None