Re: pg_dump INDEX ATTACH versus --clean option

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: pg_dump INDEX ATTACH versus --clean option
Дата
Msg-id 20210112232219.GA14665@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: pg_dump INDEX ATTACH versus --clean option  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Ryan Lambert
Дата:
Сообщение: Re: WIP: System Versioned Temporal Table
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: pg_preadv() and pg_pwritev()