Incident brief
Interval field overflow
An INTERVAL literal whose field value exceeds the storage limits of the interval type raises this data exception; here a months value larger than a signed 32-bit integer overflowed.
What lands in your log
ERROR: interval field value out of range: "2147483648 months"
In 10 seconds
- What triggers it
- Write an INTERVAL literal with a field value larger than the type can store (for example billions of months).
- Fix
- Use interval field values within range, the months field fits in a signed 32-bit integer.
- Proof
- Reproduced on PostgreSQL 18.4 → A single SELECT reproduces SQLSTATE 22015; the oversized months field is rejected while the literal is evaluated.
Fix
What to do right now
Application-level steps for this error.
- Use interval field values within range, the months field fits in a signed 32-bit integer.
- For very long spans, model them differently (a start date plus a smaller interval, or a numeric day count).
-- Use an interval field value within the type's range.
SELECT INTERVAL '1 month';For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Interval field overflow (22015) is statement-local: PostgreSQL does not retain the rejected value after the statement ends. Capture the exact bound value and statement position in application/server logs, then run this targeted validation before retrying.
Check interval style and rejected field magnitude
Validate the specific value/shape that can raise this SQLSTATE.
SHOW IntervalStyle;
-- Retest the exact bound value with an explicit interval cast.Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 18 Documentation, Appendix A. PostgreSQL Error Codes (Table A.1, Class 22, Data Exception)
22015 → interval_field_overflowRead the full section on postgresql.org →
Writing an out-of-range interval field
The months field of an interval is a 32-bit integer, so '2147483648 months' overflows and PostgreSQL raises 'interval field value out of range'.The session continues normally
The interval overflow was caught on a single statement outside a transaction block, leaving nothing to unwind before session B's next query.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Write an INTERVAL literal with a field value larger than the type can store (for example billions of months).
- 2PostgreSQL parses the literal and tries to fit the months field into a 32-bit integer.
- 3The value overflows and the statement aborts with SQLSTATE 22015.
A retention calculation multiplied a base interval by a large factor and produced a months value far beyond what the interval type can hold.
-- The error is self-contained in one statement; no schema is required.
SELECT 'no schema needed' AS setup_note;SELECT INTERVAL '2147483648 months';SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
setup_note
------------------
no schema needed
(1 row)ERROR: interval field value out of range: "2147483648 months"
LINE 1: SELECT INTERVAL '2147483648 months';
^ session_after_error
---------------------
ok
(1 row)A normal interval literal is stored without complaint once the field is within range.
Without this
Before: an out-of-range months field aborts
With this, tested
After: INTERVAL '1 month' is accepted
- A second operational test: exact SQL, raw output, measured result, and engineer notes
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Verification
- Last verified
- 2026-07-24 (isolated lab, PostgreSQL 18.4)
- Verification scope
- Verified against PostgreSQL 18.4 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.