Change report ID columns to BIGINT to avoid 32-bit integer overflow#4936
Conversation
bruntib
left a comment
bruntib
left a comment
There was a problem hiding this comment.
Thanks for the patch. I just have one question during the review.
| ('bug_path_events', False), | ||
| ('bug_report_points', False), | ||
| ('extended_report_data', False), | ||
| ('report_analysis_info', True), |
There was a problem hiding this comment.
How can this column be NULL? Couldn't we set all report_id foreign key columns as not nullable?
There was a problem hiding this comment.
Good catch. report_id being nullable is not intentional - it was defined that way in the original dabc6998b8f0 migration when report_analysis_info was added, but the application never creates rows without a report_id. If there's no analysis info for a report, no association row is created at all.
I agree we should tighten this. If you want I can do it in this PR or a seperate one.
There was a problem hiding this comment.
It would be great if this would be redesigned in this PR. Thank you in advance!
|
Thanks for the improvement! |
2 participants
Report IDs were stored as INTEGER (max ~2.1B). Large deployments can hit this limit and fail on insert. Promote reports.id and all report_id FKs to BIGINT on PostgreSQL; SQLite already supports 64-bit integers.