Re: BUG #18959: Name collisions of expression indexes during parallel Index creations on a pratitioned table.

Dilip Kumar <dilipbalaut(at)gmail(dot)com> writes:
> On Wed, Jun 18, 2025 at 10:16 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I experimented with the attached, which borrows a couple of ideas
>> from 3db61db48 to produce names like "parent_index_2" when cloning
>> indexes. While it should help with the immediate problem, I'm not
>> sure if this is acceptable, because there are a *lot* of ensuing
>> changes in the regression tests, many more than 3db61db48 caused.

> I haven't reviewed the patch itself, but I like the idea. We're now
> consistently using the parent index name for partitioned indexes,
> whether they're named or unnamed indexes. That looks like a great
> improvement. And I think including the partition number of each level
> in the index name significantly enhances its clarity, especially
> within a multi-level partition hierarchy.

A different approach that we could take --- possibly alongside doing
the above --- is to try to remove the race condition between two
sessions choosing the same index name. It doesn't look practical
to close the race window completely, but it's quite simple to make
it a whole lot shorter. If we check for a conflicting relation
name using SnapshotDirty instead of only looking for committed
pg_class rows, then the window is little more than the time needed
to insert the index's pg_class row, rather than being the whole
time needed to build the index. (The fact that the OP is working
with terabyte-sized tables is what's making this so bad for him.)

In the attached draft I only bothered to change the initial
probe for a conflicting pg_class entry. We could go further and
apply the same idea in ConstraintNameExists(), but I'm not sure
it's worth the trouble.

regards, tom lane