Amazon Redshift Query Errors: Fix COPY, Permission, Timeout and Disk Full Issues

Simple explanation

Almost every Redshift operational error fits into one of five buckets:

• Object lookup problems — the query references a table or schema the session cannot find, usually because of a search_path mismatch
• Permission problems — the user or IAM role has not been granted the privilege to access the object
• Load or parse failures — the COPY command encountered rows that do not match the expected format, delimiter, or data type
• Workload and timeout issues — the query exceeded a time limit set by Workload Manager or by a session parameter
• Storage and design issues — one node is holding a disproportionate share of the data, causing it to fill faster than the others

Once you match your error to one of the five buckets, you know which system table to query and what kind of fix to apply.

How Redshift troubleshooting works

The standard diagnostic flow:

1. Identify the exact error text. Copy the full error message. The exact wording tells you which category you are in.
2. Get the query ID. Use SELECT pg_last_query_id() for the most recent query, or find it in STL_QUERY by matching the query text and timestamp.
3. Query the relevant system view. Each error type has a corresponding view: STL_LOAD_ERRORS for COPY failures, STL_WLM_QUERY for timeouts, SVV_TABLE_INFO for skew and disk.
4. Confirm the root cause. The system views contain far more detail than the error message alone: file names, line numbers, column values, queue settings, and node-level storage figures.
5. Apply the fix. Most fixes are either a schema or privilege change, a data correction, a COPY option adjustment, or a table redesign.

Primary diagnostic views:

Quick triage: start with the symptom

Error: relation does not exist

ERROR: relation "orders" does not exist

This error means Redshift cannot find a table named orders in the schemas the current session is searching. The table almost certainly exists. It is just not where the session is looking.

Check which schema the table is actually in:

SELECT schemaname, tablename
FROM pg_tables
WHERE tablename = 'orders';

If this returns a row, the table exists. The session’s search_path does not include that schema. Fix it for the current session:

SET search_path TO sales, public;

Or qualify the table name permanently in your queries:

SELECT * FROM sales.orders;

If pg_tables returns nothing, the table does not exist. Check for typos or partial matches:

SELECT schemaname, tablename, tableowner
FROM pg_tables
WHERE tablename ILIKE '%order%';

A scheduled job that creates the table may have failed, or the table was dropped.

Case sensitivity: Redshift folds unquoted identifiers to lowercase at parse time. If the table was created with a quoted mixed-case name such as CREATE TABLE "Orders", you must reference it the same way: SELECT * FROM "Orders". Without quotes, Redshift searches for orders (lowercase) and finds nothing.

Concurrency edge case: In rare cases a session running under snapshot isolation may not see a table created by a concurrent transaction that committed after the snapshot was taken. If this appears in an automated pipeline, check transaction isolation settings.

If you are still learning how Redshift organises schemas and clusters, the Redshift architecture guide covers how schemas, nodes, and slices relate to each other.

Error: permission denied for relation

ERROR: permission denied for relation orders

The current user has no SELECT privilege on the table. Redshift requires explicit grants at both the schema level (USAGE) and the table level (SELECT).

Grant access to a specific user:

-- Schema usage first
GRANT USAGE ON SCHEMA sales TO analyst_user;

-- Then table access
GRANT SELECT ON TABLE sales.orders TO analyst_user;

Grant access to all existing tables in a schema:

GRANT USAGE ON SCHEMA sales TO GROUP analysts;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO GROUP analysts;

Cover tables created in the future:

GRANT SELECT ON ALL TABLES IN SCHEMA applies only to tables that exist at the time of the grant. Tables added later are not included. Use a default privilege to handle future tables:

ALTER DEFAULT PRIVILEGES IN SCHEMA sales
GRANT SELECT ON TABLES TO GROUP analysts;

COPY errors: bad rows, format mismatches, and failed loads

The COPY command loads data from S3 into Redshift. By default it aborts on the first row that fails validation. The top-level error message is usually generic. The actual detail is in STL_LOAD_ERRORS.

Re-run COPY with MAXERROR to collect all failures:

COPY sales.orders
FROM 's3://my-data-bucket/orders/2026/05/13/'
IAM_ROLE 'arn:aws:iam::111122223333:role/redshift-s3-role'
CSV
DELIMITER ','
IGNOREHEADER 1
MAXERROR 100;

With MAXERROR 100, COPY continues loading and accepts up to 100 row failures before aborting. After it completes, inspect the failures:

SELECT
    filename,
    line_number,
    colname,
    type,
    raw_line,
    raw_field_value,
    err_reason
FROM STL_LOAD_ERRORS
WHERE query = pg_last_copy_id()
ORDER BY line_number;

Common failure reasons and what to do:

Fix validation errors in the source data. Fix format mismatches by adjusting COPY options. Do not use ACCEPTANYDATE or IGNOREBLANKLINES as blanket suppressors without understanding what data you are silently discarding.

If your data arrives via AWS Glue before loading into Redshift, the AWS Glue overview explains how Glue handles schema inference and format conversion. The loading data into Redshift guide covers COPY command options in full.

COPY succeeded but loaded 0 rows

Confirm what COPY actually scanned:

SELECT
    filename,
    lines_scanned,
    bytes_scanned
FROM STL_LOAD_COMMITS
WHERE query = pg_last_copy_id();

If this returns no rows, COPY found no files matching the prefix. The path in your COPY statement does not match the actual S3 object keys.

Verify the S3 path directly:

# Check what is actually at the path
aws s3 ls s3://my-data-bucket/orders/2026/05/13/

# If empty, scan nearby paths to find the actual location
aws s3 ls s3://my-data-bucket/orders/ --recursive | head -20

Common path mismatches:

• Files are at orders/2026-05-13/ but COPY references orders/2026/05/13/
• Files use a different naming convention than the pipeline expects
• The upstream job failed or has not finished writing files yet
• The S3 bucket is in a different region than the Redshift cluster

IAM role check: The IAM role attached to Redshift needs s3:ListBucket on the bucket, not just s3:GetObject, to scan a prefix. Without s3:ListBucket, COPY may silently find no files instead of raising an access error. Confirm both permissions are present.

Empty files: If STL_LOAD_COMMITS shows files were scanned but lines_scanned is 0, the files exist but are empty. Trace back to the upstream job that wrote them.

For a broader look at how S3 paths, prefixes, and bucket policies interact, see the S3 overview.

Query cancelled: statement_timeout vs WLM timeout

Redshift has two separate timeout mechanisms and beginners often confuse them. They are independent, serve different purposes, and are diagnosed differently.

statement_timeout is a session-level or user-level parameter. It cancels any query that runs longer than the specified number of milliseconds, regardless of which WLM queue the query is in.

-- Check the current session setting
SHOW statement_timeout;

-- Set a timeout for the current session (in milliseconds)
SET statement_timeout TO 60000;  -- 60 seconds

-- Set a default for a specific user
ALTER USER analyst_user SET statement_timeout TO 120000;

WLM timeout is configured per queue in Workload Manager. It applies only to queries admitted to that queue and is enforced by the WLM service independently of statement_timeout.

-- Find the WLM queue and elapsed time for a specific query
SELECT
    query,
    service_class,
    elapsed_time / 1000000 AS elapsed_seconds,
    queue_elapsed_time / 1000000 AS time_in_queue_seconds,
    status
FROM STL_WLM_QUERY
WHERE query = 12345;  -- your query ID

The service_class column maps to a WLM queue. Values of 5 and above typically indicate user-defined queues. If elapsed_seconds is close to the queue timeout limit, WLM is the likely culprit.

Which timeout fired? Check SHOW statement_timeout first. If it is 0 (no limit), the cancellation came from WLM. See the comparison table in the statement_timeout vs WLM section for the full breakdown.

What to do:

• If the query is genuinely slow, optimise it before raising the timeout. See the Redshift performance optimisation guide for sort key, join, and distribution fixes.
• If the query is correct but runs in a queue with an aggressive timeout, move it to a queue with a longer limit by adjusting WLM routing rules.
• If statement_timeout is too low for interactive use, raise it at the user level rather than disabling it globally.

Disk full, skew, and table design issues

ERROR: Disk Full Detail: -----------------
node: 0, disk: /dev/xvdc, capacity: 200000000KB, used: 198000000KB

Redshift distributes rows across nodes according to the table’s distribution style and key. If the distribution key has low cardinality, or if one value dominates the data, most rows land on the same node while others sit mostly empty. That one node fills up first and triggers disk full errors even though the cluster as a whole still has available space.

How to confirm skew:

SELECT
    schema,
    "table",
    size AS size_mb,
    skew_rows,
    pct_used
FROM SVV_TABLE_INFO
WHERE schema = 'sales'
ORDER BY skew_rows DESC;

skew_rows ranges from 0 (perfectly even) to 1 (worst possible skew). A value above 0.4 indicates significant imbalance. A value near 1.0 means one node holds almost all the data.

Check the current distribution key:

SELECT "column", distkey
FROM pg_table_def
WHERE tablename = 'orders'
  AND schemaname = 'sales';

Fix skew by rebuilding with a better key:

A good distribution key has high cardinality and appears frequently in JOIN conditions. If customer_id = 1 accounts for 60% of rows, it is a poor distribution key. order_id (unique per row) distributes far more evenly.

-- Rebuild with a better distribution key
CREATE TABLE sales.orders_new
DISTSTYLE KEY
DISTKEY (order_id)
SORTKEY (order_date)
AS SELECT * FROM sales.orders;

-- Rename when ready
ALTER TABLE sales.orders RENAME TO orders_old;
ALTER TABLE sales.orders_new RENAME TO orders;

Reclaiming space: Redshift uses soft deletes. Deleted rows remain on disk until VACUUM runs. Redshift performs automatic background VACUUM, which handles most cases without intervention. After very large deletes or table rebuilds, you can run VACUUM DELETE ONLY table_name manually if you need space reclaimed immediately. Do not build this into routine pipelines.

For a full explanation of distribution styles, sort keys, and their cost implications, see the Redshift cost optimisation guide.

When to use this guide

This page covers first-pass diagnosis of common Redshift operational and query errors: things that fail outright, load nothing, or get cancelled. Use it when a query throws an error, a COPY job produces unexpected results, or a node runs out of disk space.

If your queries complete without errors but run too slowly, that is a performance problem rather than an error. Move to the Redshift performance optimisation guide for that path.

If you are comparing Redshift to another AWS database service and deciding which to use, the Redshift vs RDS comparison covers the key differences in architecture and use case.

Redshift statement_timeout vs WLM timeout

Both mechanisms can be active simultaneously. Whichever fires first wins. statement_timeout protects individual sessions from runaway queries. WLM timeout enforces SLAs across a queue of competing workloads.