-
Notifications
You must be signed in to change notification settings - Fork 891
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
Ensure fixed_schedule field is populated #6181
Conversation
The jobs framework contains two functions for loading jobs (ts_bgw_job_get_scheduled and bgw_job_from_tupleinfo). However, the ts_bgw_job_get_scheduled function did not properly populate the fixed_schedule field, which caused some bugs in the calculation of the next execution time for a job. This PR ensures the fixed_schedule field is populated properly.
@@ -377,7 +377,7 @@ ts_bgw_job_get_scheduled(size_t alloc_size, MemoryContext mctx) | |||
* handle them below. We can only use memcpy for the non-nullable fixed | |||
* width starting part of the BgwJob struct. | |||
*/ | |||
memcpy(job, GETSTRUCT(tuple), offsetof(FormData_bgw_job, fixed_schedule)); | |||
memcpy(job, GETSTRUCT(tuple), offsetof(FormData_bgw_job, initial_start)); |
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.
The fixed_schedule
field is now included and all fields starting from initial_start
are initialized below.
/* handle NULL columns */ | ||
value = slot_getattr(ti->slot, Anum_bgw_job_hypertable_id, &isnull); |
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.
Reordered the initialization order to match the order of the FormData_bgw_job
struct.
Codecov Report
@@ Coverage Diff @@
## main #6181 +/- ##
==========================================
- Coverage 81.44% 73.78% -7.67%
==========================================
Files 246 246
Lines 56974 49821 -7153
Branches 12624 12505 -119
==========================================
- Hits 46400 36758 -9642
+ Misses 8196 7231 -965
- Partials 2378 5832 +3454
... and 227 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
@erimatnor, @antekresic: please review this pull request.
|
This release contains bug fixes since the 2.12.1 release. We recommend that you upgrade at the next available opportunity. **Bugfixes** * timescale#6155 Align gapfill bucket generation with time_bucket * timescale#6181 Ensure fixed_schedule field is populated * timescale#6210 Fix EXPLAIN ANALYZE for compressed DML
This release contains bug fixes since the 2.12.1 release. We recommend that you upgrade at the next available opportunity. **Bugfixes** * timescale#6155 Align gapfill bucket generation with time_bucket * timescale#6181 Ensure fixed_schedule field is populated * timescale#6210 Fix EXPLAIN ANALYZE for compressed DML
This release contains bug fixes since the 2.12.1 release. We recommend that you upgrade at the next available opportunity. **Bugfixes** * timescale#6155 Align gapfill bucket generation with time_bucket * timescale#6181 Ensure fixed_schedule field is populated * timescale#6210 Fix EXPLAIN ANALYZE for compressed DML
This release contains bug fixes since the 2.12.1 release. We recommend that you upgrade at the next available opportunity. **Bugfixes** * timescale#6155 Align gapfill bucket generation with time_bucket * timescale#6181 Ensure fixed_schedule field is populated * timescale#6210 Fix EXPLAIN ANALYZE for compressed DML
The jobs framework contains two functions for loading jobs (ts_bgw_job_get_scheduled and bgw_job_from_tupleinfo). However, the ts_bgw_job_get_scheduled function did not properly populate the
fixed_schedule
field, which caused some bugs in the calculation of the next execution time for a job. This PR ensures the fixed_schedule field is populated properly.We have some checks in
bgw_db_scheduler_fixed
to test this code path. However, these tests use our mock framework and trigger only thets_bgw_job_entrypoint -> ts_bgw_job_stat_mark_end -> [..] -> ts_scanner_scan -> bgw_job_from_tupleinfo
code path for loading jobs and calculate the next execution for a failed job. Since the second code path can not be tested well at the moment, I did not add test cases and created the follow-up issue https://github.com/timescale/eng-database/issues/535 instead.Disable-check: force-changelog-file