22P01 — floating_point_exception
22P01
At a glance
PostgreSQL’s fixed core path installs FloatExceptionHandler for SIGFPE. The handler emits an ERROR with primary floating-point exception and detail stating that an invalid floating-point operation was signaled, probably because of an out-of-range result or an invalid operation such as division by zero.
| Field | Value |
|---|---|
| SQLSTATE | 22P01 |
| Condition | floating_point_exception |
| Status | active |
| Known present by | 7.4 |
| Locked snapshots | 9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3 |
| Macros | ERRCODE_FLOATING_POINT_EXCEPTION |
| Aliases | — |
Meaning
FloatExceptionHandler(SIGNAL_ARGS) is a signal-to-ereport(ERROR) boundary in src/backend/tcop/postgres.c; PostgresMain registers it for SIGFPE. This is a floating-point signal path, not a promise that every division or numeric range failure uses 22P01. Exact numeric division by zero and numeric range checks have their own conditions, commonly 22012 and 22003.
Diagnosis
Preserve the complete ErrorResponse and server-log context, including statement position and any routine or context fields. Inspect operand types and the expression path: distinguish a hardware or floating-point invalid operation from an exact-numeric operator that reports 22012 or 22003. The fixed handler’s detail is a diagnostic explanation, not proof that division by zero was the particular operation.
Messages
ERRORprimary:floating-point exception- DETAIL:
An invalid floating-point operation was signaled. This probably means an out-of-range result or an invalid operation, such as division by zero.
Response
Correct the arithmetic or input range, and cast deliberately before the operation when that changes the intended numeric domain. In an explicit transaction, an ERROR leaves the transaction aborted, so issue ROLLBACK or ROLLBACK TO SAVEPOINT before retrying; in autocommit, fix the expression or data first and submit it again. The cited path is ERROR, not FATAL, so a normal client backend need not be reset merely because this condition occurred.
Versions
The locked catalogue records this condition from PostgreSQL 7.4. The handler and SIGFPE registration cited here are from PostgreSQL 18.6 REL_18_6; the catalogue boundary does not prove the exact introduction of the current wording.
Related
Sources
src/backend/tcop/postgres.c#L3072-L3082
src/backend/tcop/postgres.c#L4245-L4249
The structured evidence record records the exact primary/detail, severity, and source/runtime boundary. No signal was induced for this review.