SQLSTATE 22026Severity lowLab verified

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.

What lands in your log

ERROR: bit string length 2 does not match type bit(3)

Reproduced on PostgreSQL 16.14Verified 2026-07-16 (Docker lab, PostgreSQL 16.14)Verified against PostgreSQL 16.14 in an isolated lab environment

In 10 seconds

What triggers it: Create a table with a fixed-length bit(3) column.
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.

Fix

What to do right now

Application-level steps for 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.

Fix SQL

-- Use equal-length bit strings for bitwise operations.
SELECT B'101' & B'010' AS matched_length;

For this error

See this error live on the server

Run these against the affected instance to confirm the diagnosis before you act.

String data length mismatch (22026) 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.

Compare bit-string operand lengths

Validate the specific value/shape that can raise this SQLSTATE.

SELECT bit_length(B'101') AS left_bits,
       bit_length(B'10') AS right_bits,
       bit_length(B'101') = bit_length(B'10') AS lengths_match;

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.

Schema setup

-- No table is required; the error comes from unequal bit-string operands.

The length-mismatched insert

SELECT B'101' & B'10';

SELECT 1 AS session_still_alive;

Confirming the session still works

SELECT 1 AS session_still_alive;

What PostgreSQL actually returned

Schema setup output

CREATE TABLE

The length-mismatched insert output

ERROR:  bit string length 2 does not match type bit(3)

Confirming the session still works output

 session_still_alive 
----------------------
                    1
(1 row)

Verification

PG 16.14

Last verified: 2026-07-16 (Docker lab, PostgreSQL 16.14)
Verification scope: Verified against PostgreSQL 16.14 in an isolated lab environment
Audit status: reviewed

ShareLinkedIn X

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.

See Pro on pricing Sign in

FollowSubstack LinkedInnew errors · lab notes · hiring loops

String data length mismatch

What to do right now

See this error live on the server

Compare bit-string operand lengths

What PostgreSQL is telling you

A real, single-session PostgreSQL reproduction

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.

Pro unlocks the second lab proof