Re: pg_dump INDEX ATTACH versus --clean option - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_dump INDEX ATTACH versus --clean option
Date
Msg-id 1234262.1610488585@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_dump INDEX ATTACH versus --clean option  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_dump INDEX ATTACH versus --clean option  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2021-Jan-12, Tom Lane wrote:
>> Since there's no ALTER INDEX DETACH PARTITION, it's not entirely
>> clear what to do about this.  We could possibly not emit any
>> dropStmt for partition child indexes, but that seems very likely
>> to cause problems for partial-restore scenarios.

> Yeah, it would break the case of restoring a partition that already
> exists under --clean.  (Of course, if the partition doesn't exist
> already, there's no problem, since nothing is to be dropped anyway.)

> About the only thing I can think of, is to make the dropStmt use a
> plpgsql DO block that drops conditionally (only if not an index
> partition).

Don't much like that :-(.  Aside from the fact that we'd then be
requiring plpgsql to exist to do a restore, I think this would
cause big compatibility problems in the future, since the DO block
would have to do some more-or-less-weird catalog query to find out
if the index is a partition.  We'd be locked into guaranteeing that
that query works, pretty much forever.

I think actually the cleanest fix would be to invent ALTER INDEX DETACH
PARTITION and use that as the dropStmt for the INDEX ATTACH object.
No idea how painful that would be to do, though.  I suppose it'd involve
reverting the parent index back to an invalid state.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade test for binary compatibility of core data types
Next
From: Tom Lane
Date:
Subject: Re: pgbench and timestamps (bounced)