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

From Alvaro Herrera
Subject Re: pg_dump INDEX ATTACH versus --clean option
Date
Msg-id 20210112232219.GA14665@alvherre.pgsql
Whole thread Raw
In response to Re: pg_dump INDEX ATTACH versus --clean option  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2021-Jan-12, Tom Lane wrote:

> 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.

Right.  The initial submitted patch did have DETACH, and on review we were kinda
happy that we were able to remove that and avoid indexes that can revert from valid to
invalid state.  I don't recall the precise reason, but it can probably
be found in the archives ... perhaps starting at
https://postgr.es/m/flat/CAKJS1f9G6hnahJpoLaHavrKt0uPyYZncEi2rq__kLQcrGE_FMQ@mail.gmail.com

As far as the code goes, DETACH was already in some version older than
what got committed; I suppose we could easily crib stuff from there.
It had a new alter table subcommand, so it'd not be a backpatchable fix
in that way; we'd need some different parse node representation, I
think.  One problem that was definitely not solved, is that in
multi-level partitioning setups, we would have to lock relations from
the top down.

-- 
Álvaro Herrera       Valdivia, Chile



pgsql-hackers by date:

Previous
From: Ryan Lambert
Date:
Subject: Re: WIP: System Versioned Temporal Table
Next
From: Thomas Munro
Date:
Subject: Re: pg_preadv() and pg_pwritev()