Incident brief
Logarithm of a negative number
PostgreSQL raises this data exception when ln(), log(), or log(b, x) is asked for the logarithm of a value that is zero or negative, which is undefined for the real logarithm.
What lands in your log
ERROR: cannot take logarithm of a negative number
In 10 seconds
- What triggers it
- Call a logarithm function such as ln(x) or log(x) with an argument that is zero or negative.
- Fix
- Constrain the input so the argument is strictly greater than zero before taking its logarithm.
- Proof
- Reproduced on PostgreSQL 18.4 → A single SELECT reproduces SQLSTATE 2201E: the server rejects the negative logarithm argument rather than returning a value.
Fix
What to do right now
Application-level steps for this error.
- Constrain the input so the argument is strictly greater than zero before taking its logarithm.
- Filter or clamp offending rows (WHERE x > 0), or use a CASE expression to return NULL for non-positive inputs.
-- Only take the logarithm of a strictly positive value.
SELECT ln(1);For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Logarithm of a negative number (2201E) 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.
Validate the logarithm input domain
Validate the specific value/shape that can raise this SQLSTATE.
SELECT value, value <= 0 AS outside_log_domain
FROM (VALUES (-1::numeric)) v(value);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)
2201E → invalid_argument_for_logarithmRead the full section on postgresql.org →
Taking the logarithm of a negative number
ln(-1) is undefined over the reals, so PostgreSQL raises 'cannot take logarithm of a negative number' and aborts the statement.The session continues normally
Because the LOG() call failed as a standalone statement, PostgreSQL has nothing to roll back, the next query in session B runs as if 2201E never happened.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.
- 1Call a logarithm function such as ln(x) or log(x) with an argument that is zero or negative.
- 2PostgreSQL evaluates the expression and finds the input is outside the domain of the real logarithm.
- 3The server aborts the statement with SQLSTATE 2201E instead of returning NULL or a special float value.
A reporting query computed ln() over a metric column that occasionally held zero or negative values, and the whole statement failed the moment one bad row was evaluated.
-- The error is self-contained in one statement; no schema is required.
SELECT 'no schema needed' AS setup_note;SELECT ln(-1);SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
setup_note
------------------
no schema needed
(1 row)ERROR: cannot take logarithm of a negative number session_after_error
---------------------
ok
(1 row)The same logarithm call succeeds once the argument is guaranteed positive.
Without this
Before: ln(-1) aborts the statement
With this, tested
After: ln(1) returns a value
- 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.