Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Дата
Msg-id 20190725103113.GB10546@paquier.xyz
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-bugs
On Tue, Jul 23, 2019 at 01:28:38PM +0900, Michael Paquier wrote:
> Okay.  Sharing a maximum the build of IndexInfo done as part of
> DefineIndex is something that we should do then.  Attached is a patch
> that I have been working on, introducing a new makeIndexInfo() in
> makefuncs.c. Still as IndexInfo is not a parse node but an exec node,
> I am including execnodes.h in makefuncs.h for now (perhaps somebody
> has a better idea?).  This fills the index information of the new
> entry directly from the catalog of the old entry for expressions and
> predicates.

I have been looking at this code today and extended the test cases
with more expression and predicate indexes to stress more the patch,
and it happens that I am still stuck for with makeIndexInfo().  The
header comments of makefuncs.h and makefuncs.c mention primitive
nodes, so I would need at least to update that part to mention
execution nodes.  Still I'd rather not have people scream at me as
that could be considered invasive in terms of included dependencies
for makefuncs.c :)

If we don't have the makeIndexInfo wrapper, please note that we finish
by filling in three times IndexInfo with roughly the same data in
different places, so I would like to keep it.

So, are there any opinions or ideas about that?
--
Michael

Вложения

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

Предыдущее
От: Daniel Migowski
Дата:
Сообщение: AW: BUG #15923: Prepared statements take way too much memory.
Следующее
От: Andrey Borodin
Дата:
Сообщение: Re: Logging corruption error codes