Incident brief
COPY: extra data after last column
COPY fails when an input row has more fields than the target column list expects; a three-field, tab-separated line loaded into a narrower target raises this bad-copy-format error.
What lands in your log
ERROR: extra data after last expected column
In 10 seconds
- What triggers it
- Run COPY into a table (or column list) with fewer columns than the input row provides.
- Fix
- Make the column list match the number of fields in each input row.
- Proof
- Reproduced on PostgreSQL 18.4 → A single COPY reproduces SQLSTATE 22P04; the row with an extra tab-separated field is rejected and the line is echoed in the CONTEXT.
Fix
What to do right now
Application-level steps for this error.
- Make the column list match the number of fields in each input row.
- Fix the delimiter or the file so rows have exactly as many fields as target columns; use an explicit COPY (col1, col2, ...) list.
-- Match the COPY column list to the number of fields per row.
COPY copy_target (a, b) FROM STDIN;
1 2
\.For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
Compare the COPY file field count/delimiter with the target column list; the server does not retain the rejected input line.
Target column order and count
Replace the target table. Match this count/order with one parsed input row and the COPY column list.
SELECT ordinal_position, column_name, data_type
FROM information_schema.columns
WHERE table_schema = '<schema>' AND table_name = '<table>'
ORDER BY ordinal_position;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)
22P04 → bad_copy_file_formatRead the full section on postgresql.org →
Loading a row with too many fields
The input line has three tab-separated fields but the target expects fewer, so COPY raises 'extra data after last expected column'.The session continues normally
COPY aborted the individual load outside a transaction, so the session itself is untouched and the next statement runs 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.
- 1Run COPY into a table (or column list) with fewer columns than the input row provides.
- 2PostgreSQL parses the row and finds an extra delimited field after the last expected column.
- 3The load aborts with SQLSTATE 22P04 and echoes the offending line in the CONTEXT.
An import job received a file with an unexpected extra column and every row failed COPY until the layout was reconciled.
CREATE TABLE copy_target(a int, b int);COPY copy_target (a, b) FROM STDIN;
1 2 3
\.SELECT 'ok' AS session_after_error;What PostgreSQL actually returned
CREATE TABLEERROR: extra data after last expected column
CONTEXT: COPY copy_target, line 1: "1 2 3" session_after_error
---------------------
ok
(1 row)The same COPY succeeds once the row width matches the target columns.
Without this
Before: an extra field aborts the load
With this, tested
After: the matching row loads
- A second operational test: exact SQL, raw output, measured result, and engineer notes
Card required. Cancel before day 7 and you are not charged.
Runbook to fix this
The runbook for this incident
Full step-by-step fixes for the condition behind this error: the diagnosis, the exact SQL, and output captured in the lab.
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.