CREATE INDEX CONCURRENTLY on partitioned index

Alexander Pyhalov писал 2022-02-09 15:18:
> Hi.
>
> I've looked at patches, introducing CREATE INDEX CONCURRENTLY for
> partitioned tables -
> https://www.postgresql.org/message-id/flat/20210226182019.GU20769%40telsasoft.com#da169a0a518bf8121604437d9ab053b3
> .
> The thread didn't have any activity for a year.
>
> I've rebased patches and tried to fix issues I've seen. I've fixed
> reference after table_close() in the first patch (can be seen while
> building with CPPFLAGS='-DRELCACHE_FORCE_RELEASE'). Also merged old
> 0002-f-progress-reporting.patch and
> 0003-WIP-Add-SKIPVALID-flag-for-more-integration.patch. It seems the
> first one didn't really fixed issue with progress report (as
> ReindexRelationConcurrently() uses pgstat_progress_start_command(),
> which seems to mess up the effect of this command in DefineIndex()).
> Also third patch completely removes attempts to report create index
> progress correctly (reindex reports about individual commands, not the
> whole CREATE INDEX).
>
> So I've added 0003-Try-to-fix-create-index-progress-report.patch,
> which tries to fix the mess with create index progress report. It
> introduces new flag REINDEXOPT_REPORT_PART to ReindexParams->options.
> Given this flag, ReindexRelationConcurrently() will not report about
> individual operations, but ReindexMultipleInternal() will report about
> reindexed partitions. To make the issue worse, some partitions can be
> handled in ReindexPartitions() and ReindexMultipleInternal() should
> know how many to correctly update PROGRESS_CREATEIDX_PARTITIONS_DONE
> counter, so we pass the number of handled partitions to it.
>
> I also have question if in src/backend/commands/indexcmds.c:1239
> 1240 oldcontext = MemoryContextSwitchTo(ind_context);
> 1239 childidxs = RelationGetIndexList(childrel);
> 1241 attmap =
> 1242
> build_attrmap_by_name(RelationGetDescr(childrel),
> 1243 parentDesc);
> 1244 MemoryContextSwitchTo(oldcontext);
>
> should live in ind_context, given that we iterate over this list of
> oids and immediately free it, but at least it shouldn't do much harm.

Sorry, messed the topic.
--
Best regards,
Alexander Pyhalov,
Postgres Professional