-
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
catalog/systemschema: remove default value for system.jobs.created
#91718
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Comments
ZhouXing19
added
the
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
label
Nov 11, 2022
ZhouXing19
added a commit
to ZhouXing19/cockroach
that referenced
this issue
Nov 11, 2022
When creating a job, we should use an internal executor bound to the outer txn and related metadata. We also found that in this case, if a user changes the timezone and then triggers a schema change job, the job's creation time (i.e. value createdcolumn in the system.jobs) will automatically switch to the timestamp in the updated timezone, rather than UTC. This is because we have the created using now() in the SQL statement. We now change it to be inserted always with UTC time. Informs: cockroachdb#91004 Informs: cockroachdb#91718 Release note: None
ZhouXing19
added a commit
to ZhouXing19/cockroach
that referenced
this issue
Nov 11, 2022
When creating a job, we should use an internal executor bound to the outer txn and related metadata. We also found that in this case, if a user changes the timezone and then triggers a schema change job, the job's creation time (i.e. value createdcolumn in the system.jobs) will automatically switch to the timestamp in the updated timezone, rather than UTC. This is because we have the created using now() in the SQL statement. We now change it to be inserted always with UTC time. Informs: cockroachdb#91004 Informs: cockroachdb#91718 Release note: None
craig bot
pushed a commit
that referenced
this issue
Nov 11, 2022
91679: jobs: replace the ie in Registry.createJobsInBatchWithTxn r=ajwerner a=ZhouXing19 When creating a job, we should use an internal executor bound to the outer txn and related metadata. We also found that in this case, if a user changes the timezone and then triggers a schema change job, the job's creation time (i.e. value `created`column in the `system.jobs`) will automatically switch to the timestamp in the updated timezone, rather than UTC. This is because we have the `created` using `now()` in the SQL statement. We now change it to be inserted always with UTC time. Informs: #91004 Informs: #91718 Release note: None 91734: kvserver: move checkForcedErr to kvserverbase r=pavelkalinnikov a=tbg This is a prereq to making log application stand-alone, since applying entries means calling this method to determine whether to apply an empty entry instead. This necessitated moving the constructor for NotLeaseholderError where it belongs (roachpb) and moving proposal evaluation reasons to somewhere else (I chose kvserverpb). While I was there I also renamed their type to better reflect that these are command rejections. Touches #75729. Epic: CRDB-220 Release note: None 91772: roachtest: fix typo when saving artifacts in schemachange_random_load r=postamar,ajwerner a=renatolabs Epic: None Release note: None Co-authored-by: Jane Xing <zhouxing@uchicago.edu> Co-authored-by: Tobias Grieger <tobias.b.grieger@gmail.com> Co-authored-by: Renato Costa <renato@cockroachlabs.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
C-bug
Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior.
Having
now()
as the default value for the created column insystem.jobs
is troublesome, as it may change when the user modified the session variable for the time zone. It should always be UTC time regardless of the session data.Jira issue: CRDB-21395
The text was updated successfully, but these errors were encountered: