Re: Adding REPACK [concurrently]
| От | Mihail Nikalayeu | 
|---|---|
| Тема | Re: Adding REPACK [concurrently] | 
| Дата | |
| Msg-id | CADzfLwWdc1KBZ2qNV1x7gmZtHdmAYOoq0A2Rw72O2-wEou=FRg@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Adding REPACK [concurrently] (Alvaro Herrera <alvherre@alvh.no-ip.org>) | 
| Ответы | 
                	
            		Re: Adding REPACK [concurrently]
            		
            		 | 
		
| Список | pgsql-hackers | 
Hello! On Fri, Oct 31, 2025 at 12:17 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > Here's a new installment of this series, v25, including the CONCURRENTLY > part, which required some conflict fixes on top of the much-changed > v24-0001 patch. > * cluster.c > * CLUSTER a table on an index. This is now also used for VACUUM FULL. Should we add something about repack here? > ii_ExclusinOps typo here. > * index is inserted into catalogs and needs to be built later on. Now it is only in case concurrently == true > * Build the index information for the new index. Note that rebuild of > * indexes with exclusion constraints is not supported, hence there is no > * need to fill all the ii_Exclusion* fields. Now the function supports its in !concurrently mode. Should we fill ii_Exclusion? Also, it says > If !concurrently, ii_ExclusinOps is currently not needed. But it is not clear - why not? > newInfo = makeIndexInfo(oldInfo->ii_NumIndexAttrs, > oldInfo->ii_NumIndexKeyAttrs, > oldInfo->ii_Am, > indexExprs, > indexPreds, > oldInfo->ii_Unique, > oldInfo->ii_NullsNotDistinct, > false, /* not ready for inserts */ > true, > indexRelation->rd_indam->amsummarizing, > oldInfo->ii_WithoutOverlaps); Is it ok we pass isready == false if !concurrent? Also, we pass concurrent == true even if concurrently == false - feels strange and probably wrong. > This difference does has no impact on XidInMVCCSnapshot(). Should it be "This difference has no impact"? > * pgoutput_cluster.c > * src/backend/replication/pgoutput_cluster/pgoutput_cluster.c it is pgoutput_trepack.c :) Best regards, Mikhail.
В списке pgsql-hackers по дате отправления: