I don't understand why you say that it has nothing to do with partitioning. From my perspective it has a lot to do with partitioning. On a non-partitioned table I can create 2 indexes in parallel without any problems. But for partitioned tables I have to know how Postgres is generating names for indexes on partitions, know that it is not good at generating unique names and check all my indexes to figure out whether I can create them in parallel or not. Of course you can say that you shouldn't create objects in parallel, but I was inspired by pg_repack which does exactly this.
PG Bug reporting form <noreply@postgresql.org> writes: > I think that whole problem is caused by auto-generated name for index for > partition tables. For parent table postgres is using name provided by user, > but for children tables it generates names automatically from name of the > table and fields that are used for index. But when we create index on > function it uses just function name. So for both indexes it generates name > like `child_1_lower_idx` despite the fact that one index is using > `lower(name)` and second one is using `lower(surname)`. > Why did it work with single thread? Apparently there is mechanism that tries > to solve conflicts as first index will get name: child_1_lower_idx and > second one will get child_1_lower_idx1 but for some reason this will not > work when indexes are created in parallel sessions.
Well, it won't work reliably anyway; that's inherent to the problem. There's nothing here that's specific to partitioned tables, and I'm afraid the answer is "don't do that". It's not very hard to find other examples where parallel creation of objects can hit conflicts.
