Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Дата
Msg-id 20190723042838.GB2059@paquier.xyz
обсуждение исходный текст
Ответ на Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-bugs
On Mon, Jul 22, 2019 at 05:41:26PM -0400, Tom Lane wrote:
> I think the correct fix is to nuke the code in REINDEX CONCURRENTLY that
> thinks it should use any of this infrastructure to fetch the existing
> index properties, and just have it read the catalog directly instead.

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 let BuildIndexInfo out of that as ii_ReadyForInserts can change
for system catalogs during bootstrap.  I have also reworked the test
case to just use pg_get_indexdef() which is enough to show the
original bug as after the initial REINDEX CONCURRENTLY the collation
part goes missing when testing on HEAD.  Predicates need to properly
be formatted with an implicit-AND format by the way.

Thoughts?
--
Michael

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: REINDEX CONCURRENTLY causes ALTER TABLE to fail
Следующее
От: 高 云龙
Дата:
Сообщение: A function privilege problem