Re: Issue during partition drop - Mailing list pgsql-general

From Ron Johnson
Subject Re: Issue during partition drop
Date
Msg-id CANzqJaARrCPLu4W+zJMRRhu4zTR-+Fdnij+04Jeqah9HZVJRMQ@mail.gmail.com
Whole thread
In response to Issue during partition drop  (veem v <veema0000@gmail.com>)
List pgsql-general
On Wed, Apr 29, 2026 at 10:37 PM veem v <veema0000@gmail.com> wrote:
Hi,
We have the Aurora Postgres database. And for a table with PK-FK relationships, we have been running into issues while dropping partitions using partman. We have planned to detach and drop the partitions but end up with the below error , so wanted to understand, if this is expected behaviour

Absolutely.
 
and how to handle it?
 
ERROR:  cannot drop table <table_name>_p20250202 because other objects depend on it
CONTEXT: SQL statement "DROP TABLE <table_name>_p20250202"
PL/pgSQL function drop_partition_time(text,interval,boolean,boolean,text,timestamp with time zone) line 250 at EXECUTE
PL/pgSQL function partman.run_maintenance(text,boolean,boolean) line 336 at assignment
DETAIL: constraint <constraint_name>_fkey on table <table_name> depends on table <table_name>_p20250202

Whoever designed your database determined that "orphaned child" records are a bad thing.  <constraint_name>_fkey ensures that every "child" record has a "parent" record.

If PG allows you to drop <table_name>_p20250202, then there will be "orphaned children" in your database, but the FK means you don't want orphaned children.

In order to drop <table_name>_p20250202, you must first "dispose of" (aka DELETE) the child records that depend on records in <table_name>_p20250202.  If <constraint_name>_fkey points to a table that is partitioned the same way that <table_name>_p20250202 is partitioned, then maybe you can DETACH and then DROP that table full of child records.

Only then can you drop <table_name>_p20250202.

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

pgsql-general by date:

Previous
From: Matt Magoffin
Date:
Subject: Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING
Next
From: Adrian Klaver
Date:
Subject: Re: Confirmation on concurrent SELECT FOR UPDATE with ON CONFLICT DO NOTHING