Incident brief
width_bucket count must be positive
width_bucket(operand, low, high, count) requires the bucket count to be a positive integer; passing zero or a negative count raises this data exception.
What lands in your log
ERROR: count must be greater than zero
In 10 seconds
- What triggers it
- Call width_bucket(operand, low, high, count) with a count argument of zero or less.
- Fix
- Pass a bucket count of at least 1.
- Proof
- Reproduced on PostgreSQL 18.4 → A single SELECT reproduces SQLSTATE 2201G; the histogram function rejects the non-positive bucket count.
Fix
What to do right now
Application-level steps for this error.
- Pass a bucket count of at least 1.
- If the count comes from a parameter or column, validate it (GREATEST(count, 1) or an explicit check) before the call.
-- width_bucket needs a positive number of buckets.
SELECT width_bucket(5.0, 0.0, 10.0, 5);For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
width_bucket count must be positive (2201G) 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 width_bucket bucket count
Validate the specific value/shape that can raise this SQLSTATE.
SELECT bucket_count,
bucket_count <= 0 AS would_raise_2201G
FROM (VALUES (0)) v(bucket_count);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)
2201G → invalid_argument_for_width_bucket_functionRead the full section on postgresql.org →
Calling width_bucket with a non-positive count
The fourth argument is the number of buckets and must be greater than zero, so a count of 0 raises 'count must be greater than zero'.The session continues normally
width_bucket()'s argument check failed outside any BEGIN block, so the session carries no leftover state into its next statement.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 width_bucket(operand, low, high, count) with a count argument of zero or less.
- 2PostgreSQL validates the histogram bucket count before assigning the operand.
- 3Because the count is not positive, the statement aborts with SQLSTATE 2201G and 'count must be greater than zero'.
A dashboard bucketed values into a histogram whose bucket count was derived from user input, and a zero slipped through and aborted the query.
-- The error is self-contained in one statement; no schema is required.
SELECT 'no schema needed' AS setup_note;SELECT width_bucket(5.0, 0.0, 10.0, -1);SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
setup_note
------------------
no schema needed
(1 row)ERROR: count must be greater than zero session_after_error
---------------------
ok
(1 row)The same histogram call works once the bucket count is at least one.
Without this
Before: a zero bucket count aborts
With this, tested
After: five buckets place the operand
- 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.