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
