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 →
-
Improve the names generated for indexes on expressions.
- 181b6185c79e master landed
-
Use SnapshotDirty when checking for conflicting index names.
- fdd82692230a 17.6 landed
- 75b8982eae78 15.14 landed
- 5861b1f343b5 18.0 landed
- 4b66cb18879e 13.22 landed
- 27af8b9be8c0 14.19 landed
- 1e24ea160350 16.10 landed
-
Change the names generated for child foreign key constraints.
- 3db61db48ef5 18.0 cited
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