Skip to content

Intermittent Redshift Failure: DROP/RENAME Leaves Phantom Tables and Causes "Relation Already Exists" Errors

0

We are experiencing intermittent inconsistent behavior on Amazon Redshift Serverless during routine DROP TABLE, CREATE TABLE, and ALTER TABLE RENAME operations executed via dbt. The problem presents as Redshift returning errors indicating that a table or relation already exists, even though that table has been successfully dropped in the previous statement and is confirmed to not exist when queried.

When the issue appears, Redshift reports existence of an object that is not present in the system catalog. The error interrupts dbt runs because the database believes a table name is still in use, despite the DROP being executed without failure.

We request AWS to investigate catalog consistency guarantees around DROP/RENAME operations on Redshift Serverless, as well as any known metadata-race or orphaned-object issues that could produce these symptoms.

asked 10 months ago164 views

2 Answers
0

Hello.

Can you recreate the issue by creating another Redshift Serverless cluster and repeatedly creating and dropping tables with the same queries?
If you can reproduce the issue, there may be a problem with the query you are using.
Just to be sure, is it possible that the table name has already been created in lowercase or uppercase?
https://www.reddit.com/r/PostgreSQL/comments/msp7y8/relation_already_exists_error/

If you cannot reproduce the issue, it may be an AWS problem.
In this case, AWS re:Post cannot view your AWS account, so you will need to contact AWS Support.

EXPERT

answered 10 months ago

0

Thanks for your reply.

Just to clarify: the issue is definitely not related to uppercase vs. lowercase table names. I also tested this explicitly across multiple runs, and the failures occur even when the table names are fully lowercase and consistently referenced.

I also opened a support request through AWS Support several days ago, but I haven’t received a response yet. Could you guide me on the best escalation path or the correct contact channel to ensure the Redshift team can properly investigate this catalog-consistency issue?

Thanks again for the help.

answered 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.