Re: pg_dump --if-exists --clean when drop index that is partition of a partitioned index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: jian he <jian(dot)universality(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pg_dump --if-exists --clean when drop index that is partition of a partitioned index
Date: 2025-04-15 14:28:40
Message-ID: 1568467.1744727320@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> writes:
> I have not knowledge, why pg_dump exports DROP INDEX explicitly, although
> it is redundant.

I concur that the proposed patch is probably not the right fix.
It just looks wrong and arbitrary.

My first thought about the right way to fix it was that the
INDEX ATTACH TOC entry should have a dropStmt that is "ALTER ...
DETACH PARTITION", since the way --clean works is to issue the
dropStmts in reverse order. However, there's no ALTER INDEX
DETACH PARTITION command. Also, looking at dumpIndexAttach,
there's a comment saying very explicitly not to:

/*
* There is no point in creating a drop query as the drop is done by
* index drop. (If you think to change this, see also
* _printTocEntry().) Although this object doesn't really have
* ownership as such, set the owner field anyway to ensure that the
* command is run by the correct role at restore time.
*/

My guess is that that was correct when written and has been falsified
by later changes. So I think the next thing to do is run down exactly
what broke it and then decide if that change was buggy or if the
comment is just obsolete. If it's obsolete then we have to figure
out what to do next.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-04-15 14:37:36 Re: use correct variable in error message in _allocAH function (pg_backup_archiver.c)
Previous Message Kirill Reshke 2025-04-15 14:00:21 Re: speedup COPY TO for partitioned table.