Incident brief
String data length mismatch
A bit string value was stored into a bit(n) column whose length didn't exactly match n. PostgreSQL rejected the write instead of guessing how to fit it.
In 10 seconds
- What
- String data length mismatch
- What triggers it
- Create a table with a fixed-length bit(3) column.
- The fix
- Supply a bit string whose length exactly matches the column's declared length.
- Proof
- Reproduced on PostgreSQL 16.14 → Inserting a 2-bit value into a bit(3) column was rejected with SQLSTATE 22026, naming both the supplied length and the declared length. The session was unaffected afterward.
The fix
What to do right now
The immediate, application-level response to this error.
- Supply a bit string whose length exactly matches the column's declared length.
- If you intentionally want truncation/padding instead of an error, that's a different, explicit operation — see the counterexample for what it actually does and why it's risky.
- Prefer bit varying(n) over bit(n) if the true length legitimately varies.
CREATE TABLE bitflags (a bit(3));
INSERT INTO bitflags VALUES (B'101'); -- exactly 3 bitsDiagnose
See it live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Standard triage — not specific to this error
These are canonical PostgreSQL system-catalog queries, shown as SQL to run. No sample output is attached because this is general triage, not a captured lab transcript.This SQLSTATE does not have an error-specific live snapshot yet. These are the canonical system-catalog queries you run against the affected server to see the problem in real time — standard triage, not a reproduced transcript.
What is running right now
Active backends, how long each has been running, and what it is waiting on.
SELECT pid,
state,
wait_event_type,
wait_event,
now() - query_start AS running_for,
left(query, 80) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
AND pid <> pg_backend_pid()
ORDER BY running_for DESC NULLS LAST;Who is blocking whom
Turn raw blocking PIDs into the actual queries on both sides of the wait.
SELECT blocked.pid AS blocked_pid,
blocked.query AS blocked_query,
blocking.pid AS blocking_pid,
blocking.query AS blocking_query
FROM pg_stat_activity AS blocked
JOIN LATERAL unnest(pg_blocking_pids(blocked.pid)) AS b(pid) ON true
JOIN pg_stat_activity AS blocking ON blocking.pid = b.pid
WHERE cardinality(pg_blocking_pids(blocked.pid)) > 0;Locks that are still waiting
Every lock a backend has requested but not yet been granted.
SELECT l.pid,
l.locktype,
l.mode,
l.granted,
COALESCE(c.relname, l.transactionid::text) AS object
FROM pg_locks l
LEFT JOIN pg_class c ON c.oid = l.relation
WHERE NOT l.granted
ORDER BY l.pid;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual — not paraphrased.
PostgreSQL 16 Documentation — Bit String Types
bit type data must match the length n exactly; it is an error to attempt to store shorter or longer bit strings.Read the full section on postgresql.org →
The length-mismatched insert
Per the manual's own worked example, bit(n) requires an exact length match on insert — B'10' is 2 bits, the column needs exactly 3, so PostgreSQL rejects the write rather than guessing how to pad or truncate it.Confirming the session still works
The rejected insert didn't affect the session — the next statement ran normally.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.
- 1Create a table with a fixed-length bit(3) column.
- 2INSERT a bit string that is shorter (or longer) than 3 bits.
- 3SQLSTATE 22026 is reported, naming the exact lengths involved.
One client: create a bit(3) column, then insert a bit string of the wrong length.
CREATE TEMP TABLE bitflags (a bit(3));INSERT INTO bitflags VALUES (B'10');SELECT 1 AS session_still_alive;What PostgreSQL actually returned
CREATE TABLEERROR: bit string length 2 does not match type bit(3) session_still_alive
----------------------
1
(1 row)A developer hitting this error might reach for an explicit ::bit(3) cast on the value, assuming it validates the length the same way INSERT does. That assumption was tested directly against the exact value that failed above.
Cast a 5-bit value directly to bit(3) with an explicit cast, instead of inserting it.
Without this
Above: inserting a wrong-length bit string into a bit(3) column is rejected with SQLSTATE 22026.
With this, tested
Below: explicitly casting a wrong-length bit string to bit(3) does NOT error — it silently truncates.
What Pro unlocks here
- The exact prevention SQL — copy-paste ready
- Raw psql output captured from the Docker lab
- A senior-DBA action list to take it further
- Live monitoring queries to catch it in production
- The deeper audit: fix-that-fails counterexample, GUC before/after, server-log evidence
Related & next steps
Follow the thread
Everything this error touches — jump straight to the sibling error, term, runbook, or parameter.
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Reviewed by
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed