Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Дата
Msg-id 20210421203855.GA19814@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Список pgsql-hackers
While the approach in the previous email does pass the tests, I think
(but couldn't find a test case to prove) it does so coincidentally, not
because it is correct.  If I make the test for "detached exist" use the
cached omits-partitions-partdesc, it does fail, because we had
previously cached one that was not yet omitting the partition.  So what
I said earlier in the thread stands: the set of partitions that are
considered detached changes depending on what the active snapshot is,
and therefore we *must not* cache any such descriptor.

So I backtracked to my previous proposal, which saves in relcache only
the partdesc that includes all partitions.  If any partdesc is built
that omits partitions being detached, that one must be rebuilt afresh
each time.  And to avoid potentially saving a lot of single-use
partdescs in CacheMemoryContext, in the attached second patch (which I
attach separately only to make it more obvious to review) I store such
partdescs in PortalContext.

Barring objections, I will get this pushed early tomorrow.

-- 
Álvaro Herrera       Valdivia, Chile
"Just treat us the way you want to be treated + some extra allowance
 for ignorance."                                    (Michael Brusser)

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: when the startup process doesn't
Следующее
От: Tom Lane
Дата:
Сообщение: Re: when the startup process doesn't