Re: [HACKERS] REINDEX CONCURRENTLY 2.0
От | Peter Eisentraut |
---|---|
Тема | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 |
Дата | |
Msg-id | d26799a0-14ba-7c2c-ca86-c13203a5901f@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] REINDEX CONCURRENTLY 2.0 (Sergei Kornilov <sk@zsrv.org>) |
Ответы |
Re: [HACKERS] REINDEX CONCURRENTLY 2.0
|
Список | pgsql-hackers |
On 09/12/2018 19:55, Sergei Kornilov wrote: >> <para> >> An index build with the <literal>CONCURRENTLY</literal> option failed, leaving >> an <quote>invalid</quote> index. Such indexes are useless but it can be >> - convenient to use <command>REINDEX</command> to rebuild them. Note that >> - <command>REINDEX</command> will not perform a concurrent build. To build the >> - index without interfering with production you should drop the index and >> - reissue the <command>CREATE INDEX CONCURRENTLY</command> command. >> + convenient to use <command>REINDEX</command> to rebuild them. >> </para> > This documentation change seems wrong for me: reindex concurrently does not rebuild invalid indexes. To fix invalid indexeswe still need reindex with lock table or recreate this index concurrently. > The current patch prevents REINDEX CONCURRENTLY of invalid indexes, but I wonder why that is so. Anyone remember? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: