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

Dilip Kumar <dilipbalaut@gmail.com>

From: Dilip Kumar <dilipbalaut@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: maximilian.chrzan@here.com, pgsql-bugs@lists.postgresql.org
Date: 2025-06-20T11:29:10Z
Lists: pgsql-bugs, pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Improve the names generated for indexes on expressions.

  2. Use SnapshotDirty when checking for conflicting index names.

  3. Change the names generated for child foreign key constraints.

On Fri, Jun 20, 2025 at 2:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Dilip Kumar <dilipbalaut@gmail.com> writes:
> > 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.
>
> Since people seem to think this might be a good way to proceed,
> I spent some effort on cleaning up the regression test changes.
>
> While doing that, I decided that applying this behavioral change to
> CREATE TABLE LIKE (the original user of generateClonedIndexStmt)
> might not be such a hot idea: the regression test changes that
> that induced felt less natural than the ones involving partitioned
> indexes.  Another practical reason is that all the calls for
> partitioned indexes will call DefineIndex immediately, so the
> race-condition window for some other session to claim the same
> index name is barely wider than it was before.  But in CREATE TABLE
> LIKE, there's considerably more delay, and I think it might even
> be possible to construct counterexamples where our own process
> could try to create two identically-named indexes if we try to
> nail down the index name in generateClonedIndexStmt.
>
> So that leads me to the attached.

The patch LGTM

Excluding CREATE TABLE LIKE
> reduces the number of regression-test changes a little, but
> there's still a lot of them, implying this is a nontrivial
> behavioral change for users.  So I feel like this is not
> something to squeeze into v18 post-beta-1.  I'm thinking it'd
> be appropriate for v19 instead.  (We could perhaps back-patch
> the other SnapshotDirty patch to ameliorate the problem in the
> back branches.)

Yes, that makes sense to apply in v19 because of user visible behavior
changes in index names.  I agree the SnapshotDirty patch can give
relief for this case for back branches.

-- 
Regards,
Dilip Kumar
Google