db: migrate outstanding batches table to new times#4397
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
tgeoghegan
force-pushed
the
timg/datastore-time-precision-outstanding-batches
branch
from
0b0a65b to
cee40e6
Compare
tgeoghegan
added
the
allow-changed-migrations
Also some cleanup: the old `SqlInterval` is removed in favor of the simpler `SqlIntervalTimePrecision` (which of course we rename). Part of #4206
tgeoghegan
force-pushed
the
timg/datastore-time-precision-outstanding-batches
branch
from
cee40e6 to
2e8fa4c
Compare
| WHERE task_id = $1 | ||
| AND batch_identifier = $2 | ||
| GROUP BY batch_identifier | ||
| HAVING MAX(UPPER(client_timestamp_interval)) >= $6 |
There was a problem hiding this comment.
client_timestamp_interval is now INT8RANGE, and UPPER returns BIGINT of time precisions, right? Which means here, and further down in the get_unfilled_outstanding_batches methods, we need to use the new &task_info.report_expiry_threshold_as_time_precision_units, right?
There was a problem hiding this comment.
Yes, we do need to work in time precision units here, and that's what TaskInfo::report_expiry_threshold returns. In the previous PR in this sequence (#4395), I eliminated the last place that used the old version of that function and renamed report_expiry_threshold_as_time_precision_units.
There was a problem hiding this comment.
No need to apologize or feel silly: this stuff is subtle and tricky, and it's moved around a ton in the last two weeks. It's better to err on the side of caution here.
jcjones
left a comment
jcjones
left a comment
There was a problem hiding this comment.
sheepishly hitting approve
tgeoghegan
deleted the
timg/datastore-time-precision-outstanding-batches
branch
2 participants
Also some cleanup: we rename
SqlIntervalTimePrecisiontoSqlIntervaland delete the existingSqlInterval.Part of #4206