public inbox for [email protected]
help / color / mirror / Atom feedIssue during partition drop
2+ messages / 2 participants
[nested] [flat]
* Issue during partition drop
@ 2026-04-30 02:37 veem v <[email protected]>
2026-04-30 03:39 ` Re: Issue during partition drop Ron Johnson <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: veem v @ 2026-04-30 02:37 UTC (permalink / raw)
To: pgsql-general <[email protected]>
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 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
Regards
Veem
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Issue during partition drop
2026-04-30 02:37 Issue during partition drop veem v <[email protected]>
@ 2026-04-30 03:39 ` Ron Johnson <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Ron Johnson @ 2026-04-30 03:39 UTC (permalink / raw)
To: pgsql-general <[email protected]>
On Wed, Apr 29, 2026 at 10:37 PM veem v <[email protected]> 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!
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-04-30 03:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-30 02:37 Issue during partition drop veem v <[email protected]>
2026-04-30 03:39 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox