IDs are running out in the future
Problem
Yesterday, @NikolayS concerned on Slack https://gitlab.slack.com/archives/C3NBYFJ6N/p1535651249000100 that the id
in ci_build_trace_sections
table could be overflowed in the future. Today there are about 250 million rows in the table. This means we can create 1.8 billion more rows, however, after we've consumed the capacity, we can not create a new record. As the side-effect, some feature which uses this ci_build_trace_sections
table will broken.
Statistics on gitlab.com (Date: 31th August 2018)
Tables with SERIAL
type on id
(4byte integer - MAX: 2,147,483,647)
-
ci_build_trace_sections
... 248,269,283 (Growth rate: ? count/month) -
ci_build_trace_section_names
... ? (Growth rate: ? count/month) -
ci_job_artifacts
... ? (Growth rate: ? count/month) -
ci_builds
... ? (Growth rate: ? count/month)
Tables with BIGSERIAL
type on id
(8byte integer - MAX: 922,337,2036,854,775,807)
ci_build_trace_chunks
Actions
- Setup Prometheus alerts. If columns with auto-increment integer are about to reach the maximum value of the type, we're notified.
- Recreate the table with
bigint
type (https://hackernoon.com/the-night-the-postgresql-ids-ran-out-9430a2dbb895) - Fortunately,
ci_build_trace_sections
has not been used by actual features, yet. We can just wipe the whole date and recreate the table withBIGSERIAL
.
Edited by Shinya Maeda