Re: [HACKERS] REINDEX CONCURRENTLY 2.0
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
Дата | |
Msg-id | c7c30d5c-666f-ca8b-29ad-12b9a28f11de@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [HACKERS] REINDEX CONCURRENTLY 2.0
Re: REINDEX CONCURRENTLY 2.0 Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
Список | pgsql-hackers |
On 30/01/2019 06:16, Michael Paquier wrote: > On Tue, Jan 29, 2019 at 09:51:35PM +0100, Peter Eisentraut wrote: >> On 16/01/2019 09:27, Michael Paquier wrote: >>> index_create does not actually need its extra argument with the tuple >>> descriptor. I think that we had better grab the column name list from >>> indexInfo and just pass that down to index_create() (patched on my >>> local branch), so it is an overkill to take a full copy of the index's >>> TupleDesc. >> >> Please send a fixup patch. > > Sure. Attached is a patch which can be applied on top of what you > sent last, based on what I noticed at review, here and there. You > also forgot to switch two heap_open() to table_open() in pg_depend.c. OK, applied most of that. I didn't take your function renaming. I had deliberately named the functions index_concurrently_${task}, so their relationship is more easily visible. Anyway, that's all cosmetics. Are there any more functional or correctness issues to be addressed? Another thing I was thinking of: We need some database-global tests. For example, at some point during development, I had broken some variant of REINDEX DATABASE. Where could we put those tests? Maybe with reindexdb? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: